How to set up measurement before your first app retargeting campaign

A team launches its first retargeting campaign. Two weeks later the partner reports one number of returning users, the MMP dashboard shows another, and finance asks why user acquisition plus retargeting is bigger than the total. Nothing is broken. Five decisions were made after launch instead of before it, and now every number needs an explanation.

This article is about those five decisions. It assumes you already run paid UA, you have a base of installed users, and a partner, a self-serve DSP or a re-engagement campaign in a large ad network is about to start showing ads to people who already have your app.

Your partner can only work with what your MMP sends

A retargeting partner builds audiences from the activity it receives. It does not see your database. It sees postbacks: installs, sessions, in-app events, each with a device identifier and a timestamp. Four things follow from that.

• Postbacks must include organic users. A segment like "at least five sessions, no session for 14 days" is built from everybody who uses the app, not only from users the partner acquired. If your postback rule says "only traffic attributed to this partner", the segments stay empty.
• The event list comes from the segment list, not the other way round. A segment of users who opened a specific section of the app needs an event for that section. Write the segments first, then check which events exist, then add the missing ones to the next SDK release.
• Consent is checked in two places. The MMP checks whether the user agreed to data sharing. It does not check whether the partner is on the vendor list in your consent platform. That second check is yours, and it has to happen before postbacks start.
• The partner's clock starts at the first postback. If a segment needs 30 days of inactivity, the first user qualifies about a month after the integration goes live. Either accept that ramp-up, start with shorter windows, or ask the partner whether it accepts a historical list of users.

If a large share of your revenue comes from ads rather than purchases, the same postback plan decides whether the partner can optimise towards users who earn ad revenue. How that revenue reaches the MMP in the first place is covered in our article on ad revenue attribution.

Three windows, three decisions

Retargeting attribution in an MMP is governed by three windows. They have similar names, they are set in different places, and each one answers a different question. The names also differ between MMPs, and the same word can mean a different window in another tool, so check the definitions in yours. The examples below are hypothetical and use round numbers so the mechanics are visible.

The inactivity window decides who you are allowed to credit

The inactivity window is the minimum number of days without an app open before a click or an impression can assign the user to a retargeting campaign. Depending on the MMP it is set once per app or separately for each partner; in AdShift it is an app-level setting that applies to every retargeting link. Some large networks keep their own value inside their integration regardless, so check both.

At zero, a click can credit someone who used the app yesterday. The numbers go up, but part of those users would have come back on their own. At seven days, only users inactive for at least a week can be credited. The numbers go down and get closer to what the campaign actually caused. The window does not decide who sees the ad; the partner's segments do. It decides who you count.

A reasonable starting value is the shortest inactivity period in your partner's segments. If the tightest segment is "no session for seven days", a seven-day window means every user the partner targets can also be credited, while someone active two days ago cannot. Zero is not wrong, and some networks recommend it for their own campaigns. It is only wrong when nobody remembers choosing it.

The re-engagement window decides how long the credit lasts

The re-engagement window starts when a user who already has the app opens it after engaging with a retargeting ad. For as long as the window is open, that user's events are credited to the retargeting source. When it closes, the events go back to the original acquisition source. Another click from the same campaign inside the window does not start a new re-engagement.

The right length follows the behaviour you want to pay for. An app with daily use and a quick conversion can work with hours. A subscription or e-commerce app whose users decide over days needs days or weeks. The default in your MMP may be hours in one place and days in another, so read the value where the link or the partner configuration actually lives rather than assuming it.

The re-attribution window decides when a reinstall is a new install

The re-attribution window is already running before you launch retargeting. It counts the days since the last recorded install for each device and decides how a reinstall is treated. A download that was never recorded as an install does not reset it.

With a hypothetical 90-day window, four cases cover almost everything:

• Regular UA campaign, reinstall after 40 days: not credited to the campaign and not counted as a new install.
• Regular UA campaign, reinstall after 100 days: a new install, credited to the campaign as UA.
• Retargeting link, reinstall after 40 days: a re-attribution, credited to the retargeting source and reported as retargeting.
• Retargeting link, reinstall after 100 days: a new install, credited to the retargeting source but reported as UA.

Two consequences matter at launch. First, the re-attribution window changes how many installs your UA campaigns report, so do not change it on the same day you start retargeting; you will not be able to tell the two effects apart. Second, acquisition links must keep retargeting switched off. A link for a preinstall or a UAC campaign with retargeting enabled turns reinstalls into re-attributions and quietly moves installs from one report to another.

Your reports will show three totals, and only one of them adds up

Once the campaign runs, the MMP reports the same events from three angles. The UA view credits everything to the source that originally acquired the user. The retargeting view credits events inside a re-engagement window to the retargeting source. The unified view counts each event once and resolves the conflict in favour of the most recent qualifying touch.

Inside a re-engagement window, an event appears both in the UA view and in the retargeting view. Add the two up and you get more than the unified total. This is by design: the UA team still sees the full value of the users it acquired, and the retargeting team sees the value of the users it brought back. Tell finance before launch, not after the first report.

• Budget for retargeting: read the retargeting view.
• Budget for acquisition: read the UA view.
• Total revenue and total installs: read the unified view. It is the only number that should match your backend.
• Reconciliation with the partner: compare the count of re-engagements in the partner's panel with the retargeting view in the MMP for one full day. A gap that stays above a few percent points to postbacks, consent or a window mismatch.

Credit is not causation, so decide how you will judge the campaign

Every number above answers the question "who gets the credit". None of them answers "would this user have come back anyway". A retargeting campaign that mostly reaches users on the way back to the app will look excellent in every view and change nothing in your business.

The minimum test is a holdout. Take the users who qualify for the partner's segments, keep a share of them out of the campaign, and compare the two groups after the first full window: how many came back, and how much revenue they produced per user. The partner's segments already define the population, so the only extra work is excluding part of it. If the base is too small for a clean split, compare the segment's return rate before launch with the rate after launch, and say out loud that seasonality is in that number.

The question that eventually decides renewal with the partner is simple: what did it cost to bring back a user who would not have returned without the campaign, compared with the cost of acquiring a new user of the same value? Everything in this article exists so that you can answer it after the first cycle instead of guessing.

The checklist before the first impression

1. The partner's segment list with thresholds: sessions, days of inactivity, events.
2. The event list derived from those segments, shipped in the SDK and visible in the MMP.
3. The partner on the vendor list of your consent platform.
4. Postbacks to the partner include organic users.
5. Inactivity window set, with the reason written down.
6. Re-engagement window set deliberately on the link or in the partner configuration.
7. Re-attribution window left unchanged, with its value noted.
8. Retargeting switched off on every acquisition link.
9. Finance and the UA team know that UA plus retargeting exceeds the unified total.
10. A holdout or a baseline agreed before the first impression.

The list looks long for a campaign that might start with a small budget. It is shorter than the meeting in which somebody tries to explain, after the fact, why three reports disagree. Measurement after the install is the hard part of mobile marketing, and retargeting is where that becomes visible; we wrote about why.

What this setup will not solve

Windows and postbacks make the numbers consistent. They do not make the campaign good. They will not fix creative, bids, frequency or the partner's segment logic, and they do not replace an incrementality test when retargeting becomes a large share of the budget. At that point a formal test with a control group and a significance threshold is the only way to know whether the spend changes anything.

They also will not recover history. If the partner starts receiving postbacks today, nothing you set in the MMP tells it what users did last month. Plan the ramp-up, or plan the historical list, before the launch date is announced.