Google Wallet as an Ad Outcome: Skipping the Cold Start Problem

An architecture note on shipping Google Wallet pass delivery without creating a new placement type

When I set out to add Google Wallet pass delivery to ApexAds, the obvious approach was also the wrong one. Build a new ad format called WalletAd, give it its own placement type, and let publishers request it directly.

That approach would have shipped. It also would have died on arrival.

The problem nobody mentions when they pitch a new ad format

A new placement type is only as good as the demand behind it. No DSP wakes up with budget allocated to an opaque wallet placement they have never seen before. Fill rate for a brand new, unproven format hovers near zero, because the entire programmatic ecosystem (the bidders, the creative pipelines, the budget allocation logic) is built around a small set of well understood formats: banner, interstitial, native, video.

So the real engineering question was not how to render a Google Wallet pass. It was how to get demand side platforms to bid on something they have never had to think about.

The fix: make it a feature, not a format

Instead of a new placement type, I implemented Wallet as an optional capability layer sitting on top of formats that already have deep, liquid demand, specifically Interstitial and MRECT Banner. No new placement type. No new auction category. No DSP integration work required to participate.

Here is the mechanism. When the SDK’s wallet module is installed, it signals imp.ext.wallet_supported = true inside the existing OpenRTB bid request, the same request, the same auction, the same demand pool that already bids on interstitials and banners every day. If a DSP wants to respond with a wallet offer, it can attach a signed pass JWT inside ext.wallet on its normal bid response. If it does not, nothing changes. The ad renders exactly as a standard interstitial or banner always has.

kotlin

// Application.onCreate() — one line activates wallet CTAs across all eligible ads
ApexAds.init(this, config)
WalletAdExtension.install()

That is the entire integration surface for a publisher. No changes to existing InterstitialAd or BannerAd code. The wallet CTA, a Save to Google Wallet panel, appears automatically when a bid response happens to carry the ext.wallet block, and disappears automatically when it does not.

What happens end to end

WalletAdExtension.install() → SDK registers WalletDelegate

Ad load → bid request includes ext.wallet_supported=true
        → exchange returns BidResponse with ext.wallet { pass_jwt, cta_text }
        → SDK renders the normal ad PLUS a wallet CTA panel

User taps CTA → WalletPassManager.savePassesJwt()
             → Google Wallet confirms save
             → onWalletPassSaved() fires to the publisher
             → save_tracking_url pixel fires for attribution

Two things matter about that flow. First, the wallet outcome is additive. The underlying ad still renders and still counts as a normal impression even if the user ignores the CTA entirely. Second, the dependency on Google Play Services Wallet (play-services-wallet) is scoped only to the optional sdk-wallet module. A publisher who never calls WalletAdExtension.install() never pulls that dependency into their app at all. Zero leakage, zero cost for publishers who do not want it.

Why this is genuinely useful for engagement, not just a gimmick

The advertiser case for this is straightforward once you separate it from another button on an ad. A loyalty card, a coupon, or an event ticket saved to a user’s Google Wallet is something that persists on their device after the ad impression is gone. A standard interstitial’s influence ends the moment the user dismisses it. A saved wallet pass can resurface at checkout, near a store location, near an expiry date, entirely outside the ad experience that originally delivered it.

That changes what an ad impression can accomplish. Instead of a single moment of attention, it becomes a small persistent object on the user’s phone that the user chose to keep. The action is also opt in and explicit. Tapping save is a clear, deliberate signal of interest, which is a meaningfully stronger engagement signal than a passive impression or even a click through.

For publishers, the advantage is that this comes for free on inventory they already monetize. No new SKU to sell, no new placement to explain to a sales team, no separate integration. It rides on the interstitial and banner inventory that already exists.

I want to be careful here and not invent numbers I do not have. I have not run this in production against real advertiser demand, so I am not going to claim a specific lift percentage. Anyone who tells you a precise engagement uplift for a feature that has not shipped to real traffic is making it up. What I can say with confidence is the logical case above. Persistence beyond the impression, explicit opt in intent, and zero new integration cost for the publisher are all real structural advantages, independent of what the eventual numbers turn out to be.

What I still need to solve before this is more than a strong prototype

I would rather be precise about what is unfinished than oversell a demo as production ready. A few real gaps remain.

The extension is not a standard yet. ext.wallet is a non standard OpenRTB extension I defined myself. It works because my own mock exchange and SDK agree on the contract, but a real DSP has no reason to populate that field unless there is an actual standard, or unless I integrate directly with specific demand partners one at a time. Getting from works in my demo exchange to DSPs actually populate this in the wild is a business and standards problem as much as an engineering one.

No production fill rate data exists. Everything above about engagement value is a reasoned hypothesis, not a measured result. The honest next step is a real pilot with actual advertiser demand, not just my own mock auction.

Pass lifecycle after the save is unhandled. Once a user saves a pass, what happens when the underlying offer expires, or the advertiser wants to push an update to a pass that is already on someone’s device? Google’s Wallet API supports pass updates, but I have not built that update path yet. Today it is save once and done.

Attribution stops at the save event. I track onWalletPassSaved and fire a tracking pixel at that moment, but I do not yet close the loop on what happens after, whether the pass was actually redeemed in store or used at all. Without redemption level attribution, advertisers are buying a save event, not a verified outcome.

No iOS equivalent. This is an Android only implementation tied to Google Wallet. An Apple Wallet counterpart would need its own pass signing and save flow, and right now that does not exist in this SDK.

Device and Play Services availability is not fully guarded. Not every Android device has Google Play Services, and the SDK needs to degrade gracefully, ad renders normally, CTA simply does not appear, rather than risk any failure path. That fallback exists conceptually in the design but deserves more explicit device capability testing than it has had so far.

None of these are reasons the architecture is wrong. They are the actual distance between an industry first feature in a well designed SDK and something a real ad exchange would deploy to production traffic. I would rather name that distance honestly than imply this is further along than it is.

The takeaway

The interesting decision here was not the Google Wallet integration itself. It was recognizing that a new capability does not need a new ad format to exist. If you can express a new outcome as an extension on top of formats that already have deep demand, you skip the cold start fill rate problem entirely. That is a pattern I would apply again before reaching for let’s invent a new placement type the next time a new ad outcome needs supporting.

Code and full architecture diagrams for ApexAds, including the wallet module, are available on GitHub.



