DOOH Exposure to Mobile Retargeting, Built and Measured

In Brazil this is an Android project. Android runs at roughly 83 percent of mobile devices here on StatCounter's numbers, and since ATT the iOS side of a screen exposure match is not addressable at any scale worth building a pipeline for. If your app's revenue is concentrated in iOS users, the honest answer is that this channel will reach the wrong half of your base, and we should stop at that sentence rather than at the invoice. What gets built: Exposure comes from the supply platform's bid-level logs, with latitude, longitude and timestamp per play, which means the screen operator has to be one that returns them. Vistar and Hivestack do; several networks selling direct do not, and that decides which inventory can be part of this at all. Those exposures are matched to advertising IDs through a mobility panel under a signed data processing agreement, the resulting audience is pushed into your DSP or your MMP's audience layer, and the mobile creative is sequenced to continue the screen creative rather than repeat it. AppsFlyer or Adjust handles the install-side plumbing; I work in whichever one you already run and do not propose migrating. The threshold that decides whether to build it: The exposure pool needs to match around two hundred thousand unique devices a month for retargeting frequency to reach a level where the second impression exists. Below that, most matched users see the mobile creative once, and a single impression is not retargeting, it is a rounding error with a pipeline attached. I check this against the actual screen list before any integration work starts, and I have told clients not to build it. How the result is read: I do not report DOOH-attributed installs. Device-level last-touch on an exposure match is a number that only ever goes up, and it will survive any internal challenge precisely because nobody can check it. The read is a geo holdout: matched test and control regions, four to six weeks, analysed with GeoLift or a Bayesian structural time series. That design needs roughly two thousand installs a month across the test regions to resolve a ten percent lift at conventional power. Under that volume, the recommendation is to skip the measurement build entirely and run the channel on judgement, which is cheaper and more honest than a test that cannot answer. Data protection: Location data under the LGPD needs a stated legal basis, a processing agreement with the panel, and a retention limit that someone actually enforces. I do not build geofences on hospitals, clinics, places of worship or schools regardless of what the panel technically permits, because the inference is sensitive and the exposure is not worth the ANPD conversation. This is a refusal, not a negotiation, and it stays in the scope document. Not included: No app store optimisation or store creative. No rebuild of your in-app event taxonomy beyond the two or three events the holdout needs to read. No CDP or warehouse integration work. No SKAdNetwork or AdAttributionKit strategy, which is a different specialism and a different reason to hire someone. Who should not book this: Apps below the volume threshold, where the correct advice is to spend on the screens and stop there. Teams that need a per-screen attribution dashboard for internal reporting, because I will not produce one. Anyone whose measurement expectations were set by a vendor deck showing device-level conversion paths from an outdoor screen. Markets: Brazil and LATAM primarily, with the same architecture built elsewhere where the panel coverage and legal basis hold.