A Production-Ready Architecture for Google Ad Manager, Google Demand, Meta Audience Network, and SDK Bidding
When monetizing multiple Android or iOS applications through Google Ad Manager (GAM), one of the most important inventory-design decisions is whether all applications should share the same ad units or whether each application should have its own dedicated ad units.
For example, suppose a publisher operates five Android applications, and every application contains three advertising formats:
320×50 banner
Interstitial
Rewarded
A simple implementation might reuse three common GAM ad units across every application:
text
/banner
/interstitial
/rewarded
Although this can technically work, it is usually not the best architecture for a serious production monetization platform.
A better approach is to create separate ad units for each application and each major placement or format, while sharing higher-level demand and monetization configurations where appropriate.
This becomes especially important when Google Ad Manager is being used as the central ad server and multiple sources of demand—such as Google programmatic demand, Meta Audience Network SDK Bidding, and direct campaigns—are competing for inventory.
1. Recommended Architecture
A scalable architecture looks like this:
text
Mobile Apps
│
│
▼
Google Mobile Ads SDK
│
▼
Google Ad Manager
│
├── Direct Campaigns
│
├── Google Programmatic Demand
│
├── Meta Audience Network
│ └── SDK Bidding
│
└── Other Demand Partners
└── Bidding / Mediation
Google Ad Manager becomes the central monetization and decisioning layer.
The application does not need to manually determine whether Google, Meta, or another demand source should display the advertisement.
Instead, the application requests an ad from its GAM ad unit, and the monetization stack determines the appropriate eligible demand source.
For example:
text
Android App
│
│ Request Rewarded Ad
▼
GAM Rewarded Ad Unit
│
├── Direct Campaign
├── Google Demand
└── Meta SDK Bid
│
▼
Winning Demand
│
▼
Ad Displayed
This architecture becomes considerably easier to manage when each application has clearly separated inventory.
App A ─┐
App B ─┼──> /banner
App C ─┘
App A ─┐
App B ─┼──> /interstitial
App C ─┘
App A ─┐
App B ─┼──> /rewarded
App C ─┘
This is simple initially.
However, as the number of applications and advertising partners increases, several problems appear.
3. Problem: App-Level Reporting Becomes More Difficult
Suppose three applications generate the following performance:
App
Requests
Impressions
Revenue
eCPM
App A
1,000,000
900,000
$1,800
$2.00
App B
500,000
400,000
$400
$1.00
App C
300,000
270,000
$810
$3.00
With separate ad units, these differences are naturally visible through inventory reporting.
With common ad units, additional dimensions, targeting values, or application-level reporting logic may be required to understand which inventory generated the revenue.
A good monetization architecture should make this distinction obvious.
4. Problem: Different Apps Can Have Very Different CPMs
Not every application produces the same advertising value.
This architecture can scale from a few applications to a large portfolio without redesigning the inventory structure.
9. Meta Audience Network Should Follow the Same Principle
If Meta Audience Network is being used through GAM SDK Bidding, Meta inventory should also be organized by application.
Avoid creating one universal Meta banner placement and sharing it indiscriminately across every application.
Instead:
text
Meta Property: App A
Banner Placement
Interstitial Placement
Rewarded Placement
and:
text
Meta Property: App B
Banner Placement
Interstitial Placement
Rewarded Placement
Conceptually:
text
GAM App A Banner
│
▼
Meta App A Banner Placement
GAM App A Interstitial
│
▼
Meta App A Interstitial Placement
GAM App A Rewarded
│
▼
Meta App A Rewarded Placement
This provides a clean one-to-one relationship between inventory and the corresponding Meta placement.
11. What Can Be Shared Across Applications?
Separate ad units do not mean that everything must be duplicated.
This distinction is important.
A publisher may separate:
text
App
Ad Unit
Placement
Reporting
while sharing:
text
Demand Partners
Bidders
Certain Yield Groups
Pricing Strategies
Reporting Dashboards
SDK Infrastructure
A simplified architecture might therefore be:
text
Google Ad Manager
│
┌────────────────┼────────────────┐
│ │ │
Google Demand Meta Bidder Direct Demand
│ │ │
└────────────────┼────────────────┘
│
Shared Monetization Layer
│
┌───────────────────┼───────────────────┐
│ │ │
App A App B App C
│ │ │
┌─────┼─────┐ ┌─────┼─────┐ ┌─────┼─────┐
Banner Inter Reward Banner Inter Reward Banner Inter Reward
This combines clean inventory separation with centralized monetization management.
12. Yield Groups Do Not Necessarily Need to Be Duplicated
A common misconception is:
"If I create separate ad units for every application, I must also create completely separate yield groups for every application."
Not necessarily.
Suppose ten Android applications use Meta bidding for rewarded advertisements.
A shared targeting strategy may be possible:
text
Yield Group:
Android Rewarded – Meta Bidding
targeting:
text
App A Rewarded
App B Rewarded
App C Rewarded
...
This reduces administrative overhead.
However, separate yield groups can be useful when different applications require:
Different demand partners
Different geography
Different monetization strategy
Different experiments
Different partner mappings
Different operational control
A reasonable starting strategy is therefore:
text
Ad Units:
Separate
Demand/Bidder configuration:
Shared where appropriate
Yield Groups:
Shared when behavior is genuinely common
Separate when optimization requires it
13. Why This Architecture Improves Reporting
Separate ad units provide a very useful reporting hierarchy.
You can analyze:
text
Portfolio
↓
Application
↓
Platform
↓
Ad Format
↓
Placement
Requests
Matched Requests
Impressions
Fill Rate
Clicks
CTR
Revenue
eCPM
at any meaningful level.
14. Example Monetization Dashboard
Imagine the following data:
App
Format
Requests
Fill
eCPM
Revenue
Rush2048
Banner
1.2M
92%
$0.80
$883
Rush2048
Interstitial
400K
88%
$3.20
$1,126
Rush2048
Rewarded
250K
95%
$5.10
$1,211
StickWalker
Banner
800K
85%
$0.60
$408
StickWalker
Interstitial
300K
82%
$2.50
$615
StickWalker
Rewarded
150K
91%
$4.00
$546
Immediately, it becomes apparent that:
text
Rush2048 Rewarded
is particularly valuable.
The publisher can then investigate why and optimize accordingly.
15. Demand-Source Reporting Becomes More Valuable
Once multiple bidding partners are introduced, the publisher may want to understand:
text
Google Demand
vs
Meta
vs
Other Demand
For example:
App
Demand
Impressions
Revenue
eCPM
Rush2048
Google
500K
$1,000
$2.00
Rush2048
Meta
300K
$900
$3.00
StickWalker
Google
350K
$525
$1.50
StickWalker
Meta
150K
$330
$2.20
This can expose significant differences between applications.
Perhaps Meta performs extremely well for one game's audience but Google performs better in another application's geography.
Separate inventory makes these patterns easier to understand and act upon.
16. Better Direct Campaign Targeting
Google Ad Manager is not only a mediation platform.
It is also an ad server.
Suppose an advertiser wants to advertise only inside:
text
Rush2048
With separate inventory, the campaign can target:
text
/apps/rush2048/*
without affecting other applications.
Another advertiser might want:
text
All Gaming Apps
Android
Interstitial only
Bangladesh
A structured inventory hierarchy makes these targeting requirements much easier to implement.
17. Better Troubleshooting
Suppose Meta suddenly stops filling rewarded advertisements in one application.
With separate inventory, you can isolate:
text
App:
Rush2048
Format:
Rewarded
GAM Ad Unit:
/apps/rush2048/android/rewarded
Meta Placement:
Rush2048 Android Rewarded
and test that path independently.
With shared inventory, troubleshooting becomes more difficult because traffic from several applications may be mixed together.
18. Better Policy and Risk Isolation
Applications can encounter different monetization problems.
For example:
text
App A
Normal
App B
Policy warning
App C
Abnormal traffic investigation
Although inventory separation does not by itself eliminate account-level or platform-level policy risk, it provides much clearer operational boundaries.
It becomes easier to:
Disable a problematic placement
Stop a specific app's inventory
Change targeting
Investigate invalid traffic
Compare unusual CTR
Inspect fill-rate changes
Run controlled tests
without unnecessarily changing every application.
19. Better A/B Testing
Suppose you want to test whether adding another demand partner increases rewarded revenue.
You could run:
text
App A Rewarded
Google + Meta
against:
text
App B Rewarded
Google + Meta + Network X
or create more controlled inventory/traffic experiments.
Separate ad units make experiments easier to design, observe, and roll back.
20. Do Not Make the App Perform the Auction
The mobile application should generally not contain custom logic such as:
text
Ask Google for CPM
Ask Meta for CPM
if Meta CPM > Google CPM:
show Meta
else:
show Google
That is not the architecture being built here.
Instead:
text
App
│
│ GAM Ad Request
▼
Google Ad Manager
│
├── Direct Demand
├── Google Demand
├── Meta SDK Bidding
└── Other Eligible Demand
│
▼
Ad Decision
│
▼
App Displays Ad
The app remains primarily responsible for requesting and rendering the advertisement, while GAM and the relevant SDK bidding/mediation mechanisms handle demand competition.
21. Recommended Architecture for Three Ad Formats
For an application with banner, interstitial, and rewarded inventory:
text
Android App
│
Google Mobile Ads SDK
│
▼
Google Ad Manager
│
┌────────────────────┼────────────────────┐
│ │ │
Direct Campaigns Google Demand Meta SDK Bidding
│ │ │
└────────────────────┼────────────────────┘
│
Ad Decisioning
│
┌─────────────────┼─────────────────┐
│ │ │
Banner Interstitial Rewarded
320x50
Each application should have its own three primary inventory units.
22. Scaling to Ten Applications
With ten applications and three formats per application, there would initially be approximately:
This provides both centralized monetization and app-level inventory isolation.
30. Final Recommendation
For a multi-app publisher, do not use one common banner, interstitial, and rewarded ad unit across every application as the default architecture.
Instead, use:
text
One GAM Network
│
├── App A
│ ├── Banner
│ ├── Interstitial
│ └── Rewarded
│
├── App B
│ ├── Banner
│ ├── Interstitial
│ └── Rewarded
│
└── App C
├── Banner
├── Interstitial
└── Rewarded
Then centralize the parts that benefit from being shared:
text
Google Demand
Meta SDK Bidding
Other Demand Partners
Direct Campaign Management
Reporting Infrastructure
Reusable Mobile SDK Code
The guiding principle is:
Separate inventory by application and meaningful placement, while centralizing demand management and reusable infrastructure wherever practical.
This architecture provides better reporting, easier troubleshooting, more precise targeting, cleaner Meta mapping, stronger experimentation capabilities, and significantly better scalability.
For a publisher planning to grow from a few applications to dozens or hundreds, establishing this structure early avoids a much more difficult inventory migration later.
