> ## Documentation Index
> Fetch the complete documentation index at: https://docs.almedia.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Verify attribution

> Confirm Almedia Link events are reaching your MMP correctly, and what to check when the numbers disagree.

Attribution failures are quiet. A misconfigured postback does not throw an error — it produces
an integration that looks like it works and reports the wrong numbers, which is usually caught
weeks later during a revenue reconciliation. This page is the check that stops that.

## Start from your setup page

The settings your dashboard should be showing are listed per MMP, screenshots included. Verify
against those first — most problems are a setting that was never switched on rather than
anything subtle:

> **[Adjust](https://docs.almedia.dev/publisher/mmp/adjust.md)**
>
> Data sharing, event mapping, probabilistic modeling, S2S.

> **[AppsFlyer](https://docs.almedia.dev/publisher/mmp/appsflyer.md)**
>
> Advanced Privacy off, 180-day window, install postback scope.

> **[Singular](https://docs.almedia.dev/publisher/mmp/singular.md)**
>
> Provider ID and API key, Send All on postbacks.

> [!WARNING]
>
> Two settings are easy to leave at their default and worth confirming by eye rather than from
> memory, because both are explicit requirements on the setup pages: AppsFlyer's `install`
> postback must be sent from **all media sources, including organic**, and Singular's
> **"Send All"** box must be checked so postbacks cover attributed and unattributed sources
> alike.

## The three failures we actually see

Almost every attribution problem on a live integration is one of these three. All of them are
silent — nothing errors, the integration looks fine, and the symptom shows up as players
earning less than they should.

> **1. Tasks do not progress**
>
> **Symptom.** Players link successfully, but their task list never ticks. The clearest tell is
> the **"Keep playing and fill the bar"** task sitting at zero.
>
> **Cause.** Ad revenue is being shared, but without the revenue value attached. The event
> arrives and carries nothing to score.
>
> **Fix.** In your MMP, open **In app Events Postback**, find
> `__ADMON_USER_LEVEL_REVENUE__` and tick **Revenue**.
>
> This matters most on high-IAA games, where ad revenue is the main thing players are scored on.

> **2. Nothing arrives after the install**
>
> **Symptom.** The install lands, and then no further events are received at all.
>
> **Cause.** Postbacks are enabled, but only for attributed users.
>
> **Fix.** Enable postbacks for **unattributed users as well**, across all media sources
> including organic. Almedia needs the unattributed stream specifically — see
> [prerequisites](https://docs.almedia.dev/publisher/prerequisites.md).

> **3. Ad revenue arrives a day late**
>
> **Symptom.** Everything works, but the **"Keep playing and fill the bar"** task only moves
> once a day, and every completion carries the same late-night timestamp. A tester who links in
> the afternoon sees nothing happen and reports the integration as broken.
>
> **Cause.** Ad revenue is being sent to Almedia on a **daily** schedule rather than in real
> time. The batch carries the previous day's revenue stamped at the end of that day, so progress
> lands the following morning while every other event credits immediately.
>
> **Fix.** Switch the ad revenue event from daily to **real time** in your MMP.
>
> This one is worth checking before a test session rather than after. It has been mistaken for a
> broken integration more than once, and nothing in the dashboard distinguishes it from a real
> failure.

> [!NOTE]
>
> If you have changed one of these, send a screenshot of the setting to `link@almedia.co` so
> it can be confirmed from our side rather than waiting to see whether the numbers move.

## Confirming events are arriving

**TODO(copy)** — how a publisher confirms events are landing, and what a correct result looks
like.

No verification procedure has been approved for this site yet, and none is guessed at here.
Naming the wrong dashboard view or the wrong expected value would send someone chasing a
problem that does not exist, or worse, sign off an integration that is broken.

Still needed:

* Where in each MMP to look for incoming Almedia events, and how soon they appear. Allow for
  some delay after go-live — events do not arrive instantly — but the expected window has not
  been pinned down.
* What a healthy volume looks like relative to installs, so an obviously-wrong number is
  recognisable.

The first things to check when events are missing are now covered above, and
`link@almedia.co` is the route when the data disagrees.

## What Almedia checks on its side

Two of the three setups already include a hand-off back to us, which doubles as a review:

* **Adjust** — you send a screenshot of the event mapping on the Data sharing page.
* **Singular** — the Provider ID and API key come from Almedia, so the connection is confirmed
  from our side when it goes live.

> [!NOTE]
>
> If the numbers disagree and the cause is not obvious, send what you are seeing to
> `link@almedia.co` rather than adjusting settings to make the totals match. A setting changed
> to fix a symptom is how attribution ends up wrong in a way nobody can reconstruct later.

***

*Unfamiliar with a term on this page? The [glossary](https://docs.almedia.dev/overview/glossary.md) explains the
vocabulary used across this site.*


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.