Most of what Amptune decides is to do nothing.

Three kinds of decision, all per user

Every event becomes a decision about one person, not a segment. The value can move on any variable your product exposes. These three run today.

How hard the next deal is

Difficulty follows each player's recent results, not a global curve. Someone losing three in a row gets an easier deal; someone on a streak gets a harder one.

level_completed (lost ×3)difficulty = easy

When the paywall shows

The paywall session is a per-user variable. High-intent players see it sooner; players still deciding whether they like the game see it later, or not this week.

session_started (#4, high intent)paywall = this session

Whether to send anything at all

A reminder is scheduled for the hour each person usually plays, capped at one a day, and dropped the moment they turn up on their own.

session_started (organic)reminder cancelled

Retention curves shrink by construction. We measure recency.

D1, D7 and D30 are anchored to the install date, so the cohort can only get smaller. That is an artefact of the measurement, not a truth about the product. Amptune's default target is long-term recency: was this person here yesterday, are they here today. Swap in any number you can measure instead, whether D30, revenue per active user, conversion to paid or session length, and the engine tunes every per-user variable that moves it.

One pipeline from event to outcome

Three stages, one contract. Each stage only reads what the previous one wrote, so every decision can be traced back to the events that caused it.

1. Shape Turns raw events into per-user state.

   Session history, usual hour, last game, results, every tunable and its current value. Deterministic holdouts live here too. Rules can read it, not write it.

2. Rules Decides who gets what, and when.

   Small declarative rules: on which event, under which condition, schedule or cancel what. They run server-side and, for prompts, in the browser from the same definitions.

3. Reach Delivers, or deliberately does not.

   Web push, APNs, FCM, in-app prompts, or a value your own code reads. Frequency caps, dedup keys and click attribution are enforced here, and every outcome is logged.

One script tag, and events from wherever you have them

The browser SDK is a single tag. It resolves consent, batches events, fetches the rule set and asks for push permission only when a rule says so. Servers, native apps and edge workers post the same events to the same endpoint.

<script
    async
    src="https://amptune.com/reach/c.js"
    data-product="YOUR_PRODUCT_ID"></script>

curl -X POST https://amptune.com/reach/v1/events \
    -H "Content-Type: application/json" \
    -d '{
      "product": "YOUR_PRODUCT_ID",
      "uid": "7f3a…b412",
      "tz": "Europe/Copenhagen",
      "events": [
        { "type": "session_start", "ts": 1789043316099,
          "payload": { "game_type": "klondike" } },
        { "type": "game_played", "ts": 1789043976285,
          "payload": { "game_type": "klondike", "outcome": "won" } }
      ]
    }'

• Consent aware: reads Google Consent Mode and stays session-only until analytics consent is granted.
• Events are batched and sent on tab close with a beacon, so session boundaries survive.
• Rules are evaluated server-side; the browser gets a cached, versioned rule set.
• Every decision, sent or held, lands in a log with its reason and outcome.

Running today

SolitairePlace has run on Amptune since September 2026: four games, one reminder a day at most, timed to each player's own habit, and every send and every hold written to the decision log. Results will be published here when there is a full month to report. Until then, no numbers.