Saved Segments in Admaxxer — cohort-based, multi-touch, MMM-aware

What is a saved segment?

A saved segment is a named, reusable filter you can apply to any analytics view in Admaxxer. Instead of re-typing the same filter combinations every time you want to look at a slice of your traffic — “mobile sessions from the US that came from Meta paid ads in March” — you build the segment once, name it, save it, and apply it from a dropdown in every dashboard view. The segment is workspace-scoped, so once you've built it, every team member can apply it without re-creating the conditions.

Three things distinguish a saved segment from a one-off ad-hoc filter: it has a name (e.g., “Top-LTV decile, US only”), it's persisted in your workspace, and it's composable — the same segment can be applied to the Acquisition card, the Pages card, the Goals card, the Cohort card, the Forecast view, and even the MMM input. Segments are computed at query time via Tinybird WHERE clauses, so applying a segment to any dashboard view returns the filtered slice in single-digit seconds for <10M-event workspaces.

Conceptually, segments answer a different question than funnels. Funnels ask “how do visitors progress through my conversion sequence?” (see /documentation/conversion-funnels); segments ask “which slice of my visitors am I looking at right now?” They compose — you can apply a saved segment to a saved funnel and see the funnel report computed only for visitors matching the segment.

What you can filter on

The fields below are the actual conditions surfaced in the segment builder at /dashboard/analytics. Each maps to a column or computed expression in Tinybird's pixel_events, visitor_payments, or visitor_lifetime tables.

Source / medium

• UTM source. The first-touch utm_source value: Meta, Google, Klaviyo, TikTok, Direct, etc. Sticky for the visitor's lifetime.
• UTM medium. The first-touch utm_medium value: paid_social, paid_search, email, organic, referral, etc. We canonicalize on short forms (paid, email) per /documentation/utm-best-practices.
• UTM campaign. The first-touch utm_campaign value (e.g., black-friday-2026). Supports exact match and LIKE wildcards ('%black-friday%').
• Last-touch source / medium. The visitor's most recent utm_source/utm_medium, distinct from first-touch. Useful for last-click attribution analysis.

Geography

• Country. ISO-3166 alpha-2 (US, GB, DE, FR, AU, etc.) derived from the visitor's IP at first pageview.
• Region. State (US), province (CA), or sub-national region. Useful for tax-jurisdiction-aware revenue analysis.
• City. The MaxMind-resolved city. Lower confidence than country; use sparingly when the visitor count is large enough to be reliable.

Device

• Device type. desktop, mobile, or tablet — classified from the user-agent at first pageview.
• OS. iOS, Android, Windows, macOS, Linux.
• Browser. Chrome, Safari, Firefox, Edge, etc.

Behavior

• Landing page. The first pageview path (post-normalization). Supports exact match and LIKE.
• Exit page. The last pageview path of the session.
• Session duration. Numeric range in seconds (e.g., > 60, between 30 and 300).
• Pages per session. Numeric range (e.g., >= 3).
• Bounced. Boolean — one pageview only, or multi-pageview session.

Revenue

• Total spent. Lifetime revenue of the visitor in workspace reporting currency. Useful for value-based cohorts.
• Payment count. Number of distinct revenue events.
• First-purchase value. The amount of the visitor's first revenue event.
• Currency. Original transaction currency (USD, EUR, GBP, etc.) before FX conversion.

Cohort

• First-touch date range. When the visitor first appeared on the site (e.g., “visitors whose first pageview was in March 2026”).
• Last-touch date range. The visitor's most recent pageview date.
• Lifetime value bucket. Top decile, top quartile, mid quartile, bottom quartile — computed from the p_ad_ltv pipe over a configurable window (90-day default).

Goal

• Fired specific goal. Boolean: did this visitor trigger goal X (e.g., __admx_signup or merchant-defined start_trial_clicked) at any point in the date window? See /documentation/custom-goals.
• Fired any goal in cohort Y. Boolean: did this visitor trigger any of a named set of goals?
• Goal count. Number of distinct goals fired by this visitor in the window.

Identity

• Identified vs anonymous. Has the visitor fired identify(user_id) at least once, mapping their visitor_id to a server-side user record?
• Returning vs new visitor. Was the visitor's first pageview inside the window, or before it?

Custom (goal metadata)

• Any goal-metadata key. If you fire track('plan_chosen', { plan: 'pro', tier: 3 }) from your storefront, you can filter on metadata.plan = 'pro' or metadata.tier > 2 in any segment. The metadata schema is goal-defined; segments only filter on keys you actually emit.

Building a segment — 3-step UI walkthrough

The segment builder lives on the dashboard, accessible from any analytics view via the “+ New Segment” button in the top-right of the filter bar.

1. Step 1: Open the segment builder. Navigate to /dashboard/analytics and click + New Segment. A side-drawer slides in from the right with an empty condition editor.
2. Step 2: Add conditions with AND/OR groupings. Click Add condition to add a single rule (e.g., source = Meta). Click Add group to create a nested AND/OR block. Within a group, conditions are AND-ed by default; toggle to OR with the chip at the top of the group. Up to five nested groups are supported. As you add conditions, a live count preview at the bottom of the drawer shows how many visitors match in the current date window. The preview updates within 200ms of each edit (Tinybird pre-aggregations make this cheap).
3. Step 3: Name and save. Give the segment a descriptive name (e.g., “Mobile Meta-paid US visitors, Black Friday 2026”) and click Save. The segment is now available in the filter dropdown of every dashboard view, every funnel, and every export, for every member of the workspace.

Example multi-condition segment: (source = Meta AND device = mobile) OR (campaign LIKE '%black-friday%'). The visual condition builder renders this as two grouped blocks — the first AND-ed inside, the two groups OR-ed together at the top level. Toggling between AND and OR is a single click; reordering groups is drag-and-drop.

The builder validates your conditions on save: if you reference a goal-metadata key that doesn't exist in any goal event, you'll see a yellow warning before save (the segment will save and apply, but match zero visitors until that key starts being emitted). If your conditions are mutually exclusive (e.g., country = US AND country = GB), you'll see a red error and save is blocked.

Where saved segments apply

Once saved, a segment is the same primitive across every analytics surface in Admaxxer:

• All dashboard views. The segment dropdown is on every /dashboard/* view: Acquisition, Geo, Goals, Pages, Tech, Cohort, Revenue, Forecast, MMM. Apply a segment, and every chart, table, and KPI on the page recomputes for that slice. See /documentation/dashboard/analytics for the full list of dashboard cards.
• Conversion funnels. Apply a saved segment to a saved funnel and the funnel report (drop-off rates, revenue rescued, time-to-conversion distribution) is recomputed for the segment's visitor cohort. See /documentation/conversion-funnels.
• MMM input. The Marketing Mix Model at /dashboard/mmm consumes a segment as a scope filter — “compute MMM only for visitors matching this segment.” Useful for region-specific MMM (e.g., “modeling US channel mix only”) or cohort-specific MMM (e.g., “modeling top-LTV cohort only”). This is unique to Admaxxer; Datafast doesn't have an MMM surface to wire segments into.
• Exports. CSV and JSON exports honor the active segment. If you have a segment applied when you click “Export,” the export contains only the rows matching the segment.
• Programmatic / API. Every /api/v1/analytics/* endpoint accepts a segment_id query parameter. Pass the ID of a saved segment, and the API returns the same analytics shape filtered to that segment's visitors. Useful for syncing a segment-scoped slice into a BI tool, a Slack digest, or a downstream cohort-analysis script. See /documentation/developer for the developer reference.

One segment, applied everywhere. That's the productivity multiplier. The cost of building a thoughtful, named segment amortizes across every dashboard you read for the rest of the segment's life.

Cohort segments — Admaxxer-unique vs. Datafast

Datafast filters operate on session-level fields: source, device, country, page. They cannot filter on visitor-level cohort attributes — first-touch month, lifetime value bucket, or multi-touch path. Admaxxer can. This is the single biggest filter-feature delta between the two products.

Three cohort-segment patterns no other privacy-first analytics tool supports:

• “Visitors whose first purchase was in March.” A first-touch-by-month cohort. Datafast doesn't expose first-touch-month as a filterable field. In Admaxxer, set cohort.first_purchase_month = 2026-03 and you have a March-cohort segment that you can apply to every dashboard view to study how that specific cohort behaves over time.
• “Visitors in the top LTV decile across this workspace.” A value-based cohort, computed from the p_ad_ltv Tinybird pipe over a 90-day projection window. Datafast doesn't compute LTV at all — segments-by-LTV is uniquely ours. Apply this segment to your Acquisition card and you'll see the per-channel mix of your most valuable customers, not your most-numerous customers. Those are different reports, and the latter is rarely what you actually want to optimize.
• “Visitors who first touched via Meta but converted via Klaviyo email.” A multi-touch path filter. The condition is first_touch_source = Meta AND last_touch_source = Klaviyo. Datafast doesn't model first-touch and last-touch as separately filterable fields, so cross-channel attribution segments aren't expressible there. In Admaxxer, this is a single two-condition segment.

Why these matter: most operator decisions are about cohorts, not sessions. “Should I increase Meta spend?” is really “does the cohort I acquired from Meta retain and pay back?” That question is unanswerable in a session-only filter system; it's a one-segment, one-dashboard apply in Admaxxer.

Multi-condition AND/OR with grouping

Conditions in Admaxxer segments compose with AND and OR, with up to five nested groups. The visual condition builder makes this explicit: you see the actual logical structure of your filter as a tree of grouped chips, not as a flat list of conditions that the system silently AND-s together.

A few patterns that benefit from explicit grouping:

• OR within source channels. “Visitors from any paid channel” is (source = Meta) OR (source = Google) OR (source = TikTok) OR (medium = paid_search). Without OR, you'd have to build four separate segments.
• AND across cohort + behavior. “Top-LTV decile visitors who landed on the pricing page” is (ltv_decile = top) AND (landing_page = /pricing). Both conditions must hold.
• Mixed OR and AND. “Mobile users from Meta or desktop users from Google” is (device = mobile AND source = Meta) OR (device = desktop AND source = Google). Two ANDed inner groups, OR-ed at the outer level.

Each condition shows a live count preview in the builder before you save. If you've set up a condition that matches zero visitors in your current date window, you'll see 0 visitors in the preview and can re-check the rule before saving an empty segment.

Performance & limits

• Computed at query time. Segments are not pre-computed. Each time a segment is applied, Tinybird runs the conditions as a WHERE clause against the relevant pipe. For a 7-day window with <10M events, this typically returns in single-digit seconds. For a 90-day window with 100M events, ~10-30 seconds.
• 50-segment limit per workspace. The UI caps saved segments at 50 to keep the dropdown manageable. Tinybird scales further; if you genuinely need more than 50 segments, contact support and we'll lift the cap.
• Each segment cached for 60 seconds after first use. Once a segment is applied to a dashboard view, the result is cached server-side in Upstash Redis for 60 seconds. Repeated views by the same or different team members in that window hit the cache, not Tinybird. The cache is invalidated automatically when new events arrive that would change the segment's matched-visitor count.
• Maximum five nested groups. The visual builder caps nesting at five groups. Most real-world segments use one or two; five is enough for almost any operator question.
• Maximum 20 conditions per segment. A single segment can have up to 20 individual conditions across its groups. This is high enough that you'll rarely hit it; segments with 20+ conditions are usually better expressed as two simpler segments composed at apply time.

Sharing & permissions

Saved segments are workspace-scoped, not user-scoped. The moment you save a segment, every member of your workspace can see it in the filter dropdown and apply it. This is intentional — segments are most valuable when they're a shared vocabulary for the team, not a private library for the individual operator.

Role-based permissions on segments:

• Owner. Can create, edit, rename, and delete any segment. Can transfer segment ownership to another team member.
• Admin / Member with analytics:write scope. Can create, edit, rename, and delete segments they created. Can apply any segment in the workspace.
• Member (default) / Read-only. Can apply any segment but not modify, rename, or delete. Read-only members are explicit on the workspace settings page; default members get write access.

For multi-tenant workspaces (e.g., agencies managing multiple brands), each workspace has its own segment library. There is no cross-workspace segment sharing — segments are isolated per tenant by design. See /documentation/team for the full role and permissions model.

vs. Datafast — what Admaxxer adds

Datafast's filters surface is a clean, well-executed implementation of session-level filtering. Admaxxer's saved segments take the same primitive and add five layers DF doesn't expose:

The MMM-input row is the highest-leverage delta: pairing a value-based cohort segment (e.g., “top-LTV decile”) with the channel-contribution model means you can ask “which channels drive my top-decile customers?” That's a question with hundreds of dollars per click of decision value, and it's not expressible in a session-only filter system.

API access

Saved segments are exposed under the public API at /api/v1/segments. The endpoint set:

• POST /api/v1/segments — create a new segment. Body: name, conditions tree (AND/OR groups), visibility (workspace-shared by default).
• GET /api/v1/segments — list all segments in the workspace. Returns id, name, condition tree, created_at, owner, last_used_at.
• GET /api/v1/segments/:id — get a single segment by ID.
• PATCH /api/v1/segments/:id — update a segment's conditions or rename. Owner / write-scope only.
• DELETE /api/v1/segments/:id — delete a segment. Owner only.
• Apply a segment to any analytics endpoint — pass ?segment_id=... as a query parameter to any /api/v1/analytics/* route, and the response is filtered.

Authentication is Bearer token; tokens are issued from /settings/api-keys. Rate limits and quota rules are documented in /documentation/developer.

Example: create a segment via curl

This creates a segment named “Top-LTV mobile US” matching mobile-device, US-country, top-decile-LTV visitors:

curl -X POST https://admaxxer.com/api/v1/segments \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Top-LTV mobile US",
    "conditions": {
      "operator": "AND",
      "rules": [
        { "field": "device_type", "op": "=", "value": "mobile" },
        { "field": "country", "op": "=", "value": "US" },
        { "field": "ltv_decile", "op": "=", "value": "top" }
      ]
    }
  }'

# Response
# { "id": "seg_abc123", "name": "Top-LTV mobile US", "match_count": 1842, ... }

Example: apply a segment to an analytics endpoint

Pass the segment_id as a query parameter on any analytics endpoint to filter the response:

curl "https://admaxxer.com/api/v1/analytics/acquisition?segment_id=seg_abc123&date_from=2026-04-01&date_to=2026-04-30" \
  -H "Authorization: Bearer YOUR_API_KEY"

# Returns the Acquisition view, filtered to the 1,842 visitors matching seg_abc123.

Five common segments to start with

Every workspace gets five seed segments out of the box. You can keep them, edit them, or delete them — they're a starting vocabulary, not a fixed library.

1. “Paid Social — Meta only.” Conditions: first_touch_source = Meta AND first_touch_medium = paid. The cleanest way to look at your Meta-paid acquisition slice.
2. “Mobile sessions, US visitors.” Conditions: device_type = mobile AND country = US. The single most common segment for US-focused DTC operators.
3. “Black Friday campaign cohort.” Conditions: utm_campaign LIKE '%black-friday%' OR utm_campaign LIKE '%bf-2026%'. Edit the dates to your campaign window. Useful for post-mortem analysis of any time-bounded campaign.
4. “Top-LTV decile.” Conditions: ltv_decile = top. The cohort that actually drives revenue. Apply this to your Acquisition card and you'll often see a different channel mix than your visitor-count Acquisition card — that delta is what most operators are missing.
5. “First-time vs returning.” Two segments, actually: visitor_recency = new and visitor_recency = returning. Apply them side by side to a funnel or a cohort report to see how new and returning behave differently.

Troubleshooting common segment issues

• “My segment shows zero visitors.” Three usual causes. (1) Date range too narrow. Segments compute over the active dashboard date window; if your segment requires events in March but the dashboard is set to last 7 days in May, you'll see zero. Widen the range. (2) AND/OR logic too strict. Multiple ANDs across rare conditions yield empty results; relax to OR or remove a condition and check the live count. (3) Condition typo. If your segment uses a UTM source value that's misspelled (e.g., FaceBook vs facebook), the segment matches zero. Open the segment, click into each condition, and confirm against the dropdown of actual values present in your data.
• “Segment count doesn't match dashboard total.” Segments are AND-ed with the dashboard's date filter. If your segment matches 5,000 visitors over the last 90 days and the dashboard is showing the last 7 days, you'll see fewer than 5,000 in the dashboard. This is correct behavior — the segment is the visitor-level filter, the date range is the time-window filter, and they compose with AND.
• “Segment count doesn't match my Shopify or Stripe order count.” Almost always an attribution-window or path-normalization issue, not a segment issue. Open /documentation/troubleshoot/sales-mismatch for the reconciliation walkthrough.
• “I can't edit a segment a teammate created.” Default member roles can apply but not edit segments owned by others. Ask the owner to either edit on your behalf or transfer ownership. Workspace owners can edit any segment.
• “Segment apply is slow.” The first apply against a fresh date window pays the Tinybird query cost (~5-30 seconds depending on event volume). Subsequent applies in the same 60-second window hit the Upstash Redis cache and return in <100ms. If your first-apply latency is consistently >30 seconds, your event volume is in the 100M+ range — talk to support about index tuning.

Related documentation

Dashboard analytics cards · Conversion funnels · Custom goals · UTM best practices · Developer / API reference · Team & workspace permissions · Sales mismatch troubleshooting