Growth marketing · Interactive lesson

The Attribution Simulator

One user, one purchase, four reporting panels. Build the journey, press play, and watch who takes credit.

Ready scenarios

Pick a scenario, press Play, then tweak the settings.

Environment

Platform

Meta data restrictions (health, finance)purchase data closed to Meta ad measurement

User journey - configure each event

DownloadDay 0 · acquisition channel:

sign_inday:0via:

Registrationday:0via:

Purchaseday:1via:

"Via" = where did the user come from right before this event? If you pick an ad, a new ad touch is created and attribution windows move with it.

Attribution window settings

Window = how long after a click an event can still be credited to that ad.

Meta window

Google Ads window

AppsFlyer last-touch

Try this: set the Meta window to 1 day; a day-2 purchase disappears from Meta. Set it to 28; it comes back.

Day 0

Scenario ready - press Play.

0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

Meta 7d

GA4: first source forever

Clicks the Facebook adDay 0

Downloads (install)Day 0

Does sign_inDay 0

RegistersDay 0

Opens directlyDay 1

PURCHASESDay 1

Meta window (7 days)Google Ads window (30 days)GA4 "first source": no expiryPurchase credit flies to the panel that claims it; if nobody claims it, it falls into the unclaimed pool

THE TRUTHFirst acquisition: Facebook (Day 0)· Purchase: Day 1 - direct

AFAppsFlyer

INSTALL (Day 0)

Facebook

SIGN_IN (Day 0)

Facebook

REGISTRATION (Day 0)

Facebook

PURCHASE (Day 1)

Facebook

Bases credit on the install source; if the last-touch rule is on, the last ad touch before the purchase takes over attribution.

GGoogle Ads

INSTALL (Day 0)

-

SIGN_IN (Day 0)

-

REGISTRATION (Day 0)

-

PURCHASE (Day 1)

-

Only counts events that have a Google click, and only if they fall inside its own window.

fMeta

INSTALL (Day 0)

counts

SIGN_IN (Day 0)

counts

REGISTRATION (Day 0)

counts

PURCHASE (Day 1)

counts

Only counts events that have an FB/IG click, and only if they fall inside its own window; the health restriction blocks purchase credit.

GAGA4 - "first source" report

INSTALL (Day 0)

facebook

SIGN_IN (Day 0)

facebook

REGISTRATION (Day 0)

facebook

PURCHASE (Day 1)

facebook

This panel models the 'first user source' dimension: every event is written to the user's FIRST source. GA4 also has a session source that can catch campaign sessions, but the purchase session is usually 'direct'.

The unclaimed pool (Direct / Organic)

%29 True organic (referral, search, store)

%29 Users who lost parameters at the store handoff

%16 Ad purchases that missed the window

%13 Users masked by ATT / privacy

Shares are illustrative; they change with your scenario and are not a real measurement.

Technical notes - this simulation is simplified on purpose

1 · No view-through: Meta in reality uses 7-day click + 1-day view; the case where someone saw the ad, did not click, and Meta still counted it is not modeled here.

2 · Meta 28 days "(legacy model)": the 28-day click window was removed in 2021; it is kept here only as a teaching lever to exaggerate what windows do.

3 · The GA4 panel models the "first user source" report: GA4's default event attribution is actually "last click (excluding direct)" and session source can catch campaign sessions. But purchase sessions are often direct opens, so share drifts toward "direct" over time in both session and first dimensions - untracked and privacy-masked traffic sit in that pool too.

4 · On iOS, GA4 is not 100% direct: AppsFlyer to GA4 iOS feeds and improving measurement attribute some traffic to its real source (in our data the iOS Google share rose to ~9%); that is why the simulation softens the line to "mostly (direct)".

5 · AppsFlyer install attribution is permanent: once an install is written to a source, every later event for that user (including a day-113 purchase) stays tied to that source for life; the "re-attribution window" does not erase history - it only limits how long a new touch can take over the credit.

6 · Unclaimed-pool shares are illustrative: the composition bar is an educational estimate derived from the selected scenario, not a real measurement.

7 · Other simplifications: day-level time resolution, collapsing AppsFlyer's probabilistic/SKAN modeling on iOS into a single label, and excluding Google view-through conversions.

This is a simulation. Your account is not.

The same window mismatches, double counting, and unclaimed pools are running in your real data right now. VEOtool finds them and turns them into a fix list.

See it on the live demo How VEOtool works