> ## 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.

# What is Almedia Link

> A plain-language explanation of Almedia Link — what it does for players, and what it does for publishers.

Almedia Link is an account link, not an ad placement. A player connects their Freecash account
from inside your game, keeps playing, and earns real rewards — cash, gift cards and in-game
currency — for progress they were already making. You get paid for every verified link.

Almedia funds those rewards. They do not come out of your economy.

## What the player does

1. They see an entry point in your game — usually a button on a screen you already have.
2. They tap it. The SDK opens the Freecash linking flow in a secure browser.
3. They link their Freecash account and return to your game.
4. They keep playing. Progress in your game becomes tasks completed on Freecash.
5. They earn cash, gift cards or in-game currency, and are notified as they hit reward
   milestones.

New and existing Freecash users both count as a verified link.

## Who does what

| You | Almedia |
| - | - |
| Place the entry point | Decides per player whether it shows at all |
| Send your app IDs and share MMP events | Creates your campaign and issues your integration keys |
| Optionally reward a player for linking | Funds every reward the player earns |

The work that normally causes integration bugs — link building, attribution parameters,
confirmation callbacks, eligibility checks — sits inside the SDK. Your engineers never touch
any of it.

The full list of what to send, and who to send it to, is on
[prerequisites](https://docs.almedia.dev/publisher/prerequisites.md).

## Why publishers integrate it

**It is quick.** Fifteen minutes of engineering gets you to a first link using the bundled UI.
A fully customised integration is measured in days, not weeks.

**It is small.** Less engineering, less QA, fewer support round-trips, because the parts that
usually break live inside the SDK rather than in your codebase.

**It pays twice.** You earn per verified link, and again when linked players discover new games
through the Earn Tab. See [how revenue works](https://docs.almedia.dev/overview/how-revenue-works.md).

**It compounds.** Linked players play more, retain better, and are worth more. Across
integrated titles that comes out at:

<ul>
  <li>
    \~15%
    Average install-to-link rate
  </li>

  <li>
    10%+
    LTV lift for linked users
  </li>
</ul>

Almedia measures that lift continuously, using automatic server-side holdout groups. Nothing
to configure on your side.

**It keeps improving without you shipping.** Eligibility, offers, supported countries and
reward logic all live server-side. When a new country or a new experience goes live, it
reaches your players immediately — not through your release cycle.

## What it is not

**It is not a replacement for your MMP setup.** Unattributed events still have to flow from
your MMP to Almedia. Without them, player progress cannot be scored and players get fewer and
worse rewards — which erodes the LTV lift the integration exists to produce.

**It is not a set of screens for your team to build.** The SDK owns the linking flow and the
reward hub. There is no WebView to configure, no URL to assemble, no navigation to intercept,
no close button to build.

**It is not a hard dependency on a recent OS.** On older systems the SDK stays dormant and
reports "not available" rather than breaking your build or crashing for your players.

**It is not an offerwall, and it does not replace your ad stack.** It sits on top of your
existing rewarded ads and IAP rather than competing with them for attention. That is the
difference from offerwall formats, which compete directly with rewarded video for the same
session.

## What it does to your existing revenue

Link adds revenue rather than moving it. Gryphon Games ran it across six titles, with roughly
70% of their revenue coming from in-app purchases:

<ul>
  <li>
    +18.6%
    Total revenue per user
    1.985 → 2.353, including all in-game revenue and Link CPA payments.
  </li>

  <li>
    +5.2%
    Day 7 retention
    11.9% → 12.5%.
  </li>
</ul>

The first figure is the one worth reading twice: it is **total** publisher revenue per user,
not Link's payments on their own. A number that includes in-game revenue could not rise if
Link were taking from it.

> **[Gryphon Games case study](https://almedia.co/resource-hub/case-studies/gryphon-games-link)**
>
> The full write-up, including how they rolled it across the portfolio.

> [!NOTE]
>
> **TODO(copy)** — player data. What a publisher needs to tell their own users, and Almedia's
> role for data the SDK sends. The public privacy policy states Almedia is a **data
> controller** but does not mention the SDK, device identifiers or partner apps at all, so
> there is nothing to transcribe. Needs legal, not a copy decision — and may belong in the
> contract rather than on this page.

Next: [what makes a placement work](https://docs.almedia.dev/overview/best-practices.md), then
[how revenue works](https://docs.almedia.dev/overview/how-revenue-works.md).

***

*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.