This page is about the audience-building recommendations in the Client API — used by Lookout and Wave to suggest who to target with an event’s campaigns. For on-site product / event recommendations (the “you might also like” surface), see the separate Affinity product. Given an event, the Client API surfaces:
  • Taste clusters — segments of likely buyers for this event.
  • Suggested clusters for a given budget and goal — what to actually spend on.
  • Expected value — predicted tickets sold and revenue for any cluster selection.
  • Default campaign parameters — sensible budget / goal / cluster defaults so you don’t ask the user to start from scratch.
All endpoints below live on the Client API (client-api.{env}.future-demand.com/api/v3) and share its auth (see Authentication).

​
Taste clusters

A taste cluster is a learned segment for one specific event. It is not a generic audience — it is “people likely to buy a ticket to this event, grouped by why.” Clusters are versioned by tc_run_id. 
GET /events/{eid}/clusters

{
  "tc_run_id": 42,
  "clusters": [
    {
      "tc":          "family_outings_munich",
      "label":       "Family outings, Munich area",
      "metric_pred": 4.2,
      "reach_estimate": 184000,
      "size_share": 0.21
    }
  ]
}
metric_pred is the model’s predicted score for this cluster on this event (higher = more likely to buy). It is on a 0–5 scale — the reference webapp converts it to a percentage for display (metric_pred / 5 * 100). size_share is the cluster’s share of the total reachable audience.

​
Suggested clusters at a budget

The Wave wizard doesn’t make the user pick clusters cold — it asks the Client API for the suggested mix at the user’s target budget and goal. 
GET /events/{eid}/suggested_tcs?budget=5000&goal=UTILIZATION
The response is minimal — a ranked list of cluster references: 
[
  { "tc": "family_outings_munich", "tc_run_id": "42" },
  { "tc": "german_metal_diehards", "tc_run_id": "42" }
]
Goals supported:
GoalWhat it optimises
UTILIZATIONFilling capacity
ROASReturn on ad spend
VISIBILITYReach / impressions
LINK_CLICKSClicks to the ticketing page
Use the enum-style goal values above — not tickets / revenue / reach. And note suggested_tcs returns only { tc, tc_run_id } per cluster; it does not return rank, expected_tickets, or expected_revenue.

​
Expected value

To get a predicted-value summary for the budget/goal: 
GET /events/{eid}/campaigns_expected_value?goal=UTILIZATION&budget=5000

{ "expected_value": "<string>" }
The response is a single expected_value string, not per-cluster breakdown. Render it as the headline outcome estimate.

​
Default campaign parameters

GET /events/{eid}/default_campaigns_parameters

{
  "total_budget":        5000,
  "goal":                "UTILIZATION",
  "tcs":                 ["family_outings_munich", "german_metal_diehards"],
  "integration_details": [],
  "conversion_id":       null,
  "custom_event_type":   null,
  "lead_form_id":        null
}
The Wave wizard pre-fills the budget input and pre-selects the clusters from this payload, and seeds integration_details, conversion_id, custom_event_type, and lead_form_id. Surface these as defaults the user can change, not hard constraints.

​
Budget min/max

GET /events/{eid}/budget_min_max?runtime_in_days=14

{ "upper_limit": 0, "lower_limit": 0 }
Returns the allowed budget range for the event at the given runtime. Use this to clamp (and visualise) the budget slider.

​
CTA suggestions

For the campaign creative editor: 
GET /setup_processes/call_to_action/?goal=UTILIZATION&has_pixel=true&lead_form_id=
Returns the list of allowed CTAs for the chosen goal. The reference webapp shows them as radio chips next to the creative form.

​
How recommendations interact with campaigns

A campaign is uniquely identified by (eid, tc, tc_run_id). When the clustering model re-runs (because the event’s data changed materially), the new run produces new clusters with a new tc_run_id. Existing campaigns keep their old run — that’s intentional, so an active campaign isn’t disrupted by a model refresh. In your UI:
  1. Lookout — read clusters and show the latest run.
  2. Wave — when starting a new setup, take the latest run and lock the tc_run_id for the duration of the wizard. When the user edits a running campaign, keep its existing tc_run_id.

​
Geo radius helper (Meta targeting)

For partners using Meta as the ad platform, the Client API also provides a radius suggestion: 
GET /fb_targeting/suggested_radius?location=Munich%2CDE&distance_unit=mile
distance_unit must be mile or kilometer (not km). Response: 
[
  { "suggested_radius": 1, "distance_unit": "mile", "city_id": "2874477" }
]
Wire the suggested radius into the location targeting widget so the user starts from a sensible default.

​
Caveats

There is no “global audience” endpoint here — these recommendations always live under /events/{eid}/. For on-site personal recommendations independent of a specific event, see Affinity.
Don’t hard-code “show top 5 clusters”. Some events have 3, some have 12. Render whatever the API returns and let the user pick within it.
Newly-ingested events without enough historical signal return clusters: [] until the platform finishes computing recommendations. The reference webapp shows an empty-state with a “still computing” message — mirror that.
A 4.2 on one event doesn’t mean the same thing as 4.2 on another. Don’t rank events by their clusters’ scores.