Attribution is how Future Demand connects observed sales to the campaigns or audience packages that drove them. Two surfaces:
  • Campaign attribution — sales adjustments tied to a specific event’s campaigns. Visible in Lookout (event detail) and Wave (campaign detail).
  • Backhaul attribution — package-level evaluation: which package segments converted, and at what rate.

​
Campaign attribution

Each post-campaign attribution result is a “sales adjustment” row attached to an event.
ActionEndpoint
List adjustments for an eventGET /campaign_results/?eid=&partner_id=
Create onePOST /campaign_results/?eid=&partner_id=&purchase=&revenue=
Delete oneDELETE /campaign_results/?id=
[
  {
    "id":         "cr_xyz",
    "eid":        "evt_abc123",
    "partner_id": "partner-id-acme",
    "purchase":   147,
    "revenue":    6615,
    "created_at": "2026-06-13T08:00:00Z",
    "source":     "automated"
  }
]
The reference webapp surfaces this:
  • On the Event detail page, as part of the daily revenue chart’s manual_adjustments overlay.
  • On the Wave campaign detail page, as the post-campaign performance card.
The platform runs the attribution job on its own schedule — there is no partner-callable endpoint to trigger it. Consume the result endpoints (/campaign_results/) instead.

​
Backhaul attribution (Package Builder)

Packages have their own attribution sub-lifecycle, scoped to one package.
ActionEndpoint
Get current settingsGET /package_builder/packages/{id}/backhaul_evaluation_details
Update settings (triggers re-eval)PUT /package_builder/packages/{id}/backhaul_evaluation_details
Read resultsGET /package_builder/packages/{id}/backhaul_evaluation
Default settings for partnerGET /partners/{partner_id}/backhaul_attribution_details
Update partner defaultsPOST /partners/{partner_id}/backhaul_attribution_details

​
Settings payload

{
  "backhaul_evaluation_attribution_window": 14,
  "backhaul_evaluation_model": "ALL_PURCHASES",
  "email_sent_date": "2026-06-01"
}
FieldValuesMeaning
backhaul_evaluation_attribution_windowinteger (days)Number of days after email_sent_date to count attributed purchases.
backhaul_evaluation_modelALL_PURCHASES, EVENTS_FROM_PACKAGE, EVENT_SERIESWhich purchases count: any purchase, only purchases of events in this package, or only purchases in the same event series.
email_sent_dateYYYY-MM-DDAnchor date — typically the day the partner sent the marketing communication using the package. Optional in partner-default settings.

​
Results shape

{
  "clusters": {
    "family_outings_munich": {
      "customers": 184,
      "items":     412,
      "purchase":  18540
    },
    "german_metal_diehards": {
      "customers": 132,
      "items":     287,
      "purchase":  12915
    }
  }
}
Aggregate client-side for header KPIs (total customers / items / revenue).

​
Choosing an attribution model

For most live-events partners:
  • EVENTS_FROM_PACKAGE — the most defensible model. Only counts ticket purchases for events that were actually in the package being evaluated.
  • EVENT_SERIES — useful when the package targeted a tour or recurring fixture and you want to credit downstream dates in the same series.
  • ALL_PURCHASES — broadest model, useful for “halo effect” reporting where the partner accepts that some attribution is coincidental.
The reference webapp lets the partner pick per package; default is set by POST /partners/{partner_id}/backhaul_attribution_details.

​
Lookout attribution model

Independently of Backhaul, Lookout’s per-event view has its own attribution selection: 
GET  /events/{eid}/attribution_model
PUT  /events/{eid}/attribution_model
This controls how the event’s daily-revenue chart attributes incoming ticket sales to campaigns vs. organic. It’s a per-event override on top of the partner-level default.

​
Putting it together

Campaign published
    │
    │  delivery (Meta / Google / ...)
    ▼
Sales flow in (via /ingest/transaction_summary or live feeds)
    │
    │  attribution job runs (overnight or on demand)
    ▼
/campaign_results/             ← partner reads here for campaign view
/package_builder/.../backhaul_evaluation  ← partner reads here for package view
The partner-side integration responsibilities are:
  1. Ingest sales data (if you’re not already feeding it from a live source).
  2. Set partner-level attribution defaults once.
  3. Per-package: optionally override the model, then poll for results.
  4. Read results into your reporting UI.
You do not orchestrate the attribution jobs themselves. The platform runs them on a schedule.