10xDotIn Product Docs

Campaign Session Stories

Configure campaign journey expectations, collect visitor behavior on managed campaign pages, and review session-level expected vs actual stories in the admin UI.

Campaign Session Stories

Use this feature when you want to understand how a visitor moved through a campaign page, where they diverged from your expected journey, and what you should do next.

This is an operator-facing feature. It does not show a story to the visitor on the live page.

What the feature does

Campaign Session Stories combine:

  • campaign page behavior tracking
  • expected-journey milestones
  • deterministic comparison between expectation and reality
  • an optional short operator summary

For each campaign session, the platform can show:

  • the ordered timeline of tracked actions
  • which milestones were completed or missed
  • which failure signals were observed
  • the current funnel stage
  • the recommended next action

When to use it

Use Campaign Session Stories when:

  • you want to track behavior on a campaign detail page, not just clicks and final conversions
  • you care about intermediate proof steps such as reading comments, reaching FAQ, or opening pricing
  • you want the platform to tell you where a session stalled
  • you want operators to review the latest session in the admin UI

Before you start

You need all of the following:

  • a campaign
  • a campaign detail page created through campaign site structure
  • the managed collector on a 10x-published page
  • structured journey expectations in the page schema
  • authenticated operator access to the admin app

If your page is not a 10x-published managed campaign page, this feature will not work in v1.

Setup workflow

1. Add campaign page tracking

In the campaign site-structure schema, define tracking.behavior.

Use sections for areas you want to watch, such as:

  • comments
  • testimonials
  • pricing
  • FAQ
  • lead form

Use triggers for derived actions you want to treat as meaningful events, such as:

  • stayed in comments for 30 seconds
  • stayed on the page for 45 seconds
  • went idle for 30 seconds
  • clicked a primary CTA

Example:

{
  "tracking": {
    "behavior": {
      "sections": [
        {
          "id": "comments",
          "selector": "#comments,.comments-thread",
          "signal": "comment_engagement",
          "track": {
            "visibility": true,
            "dwellTime": true
          }
        }
      ],
      "triggers": [
        {
          "id": "comments_dwell_30s",
          "type": "section_dwell_threshold",
          "sectionId": "comments",
          "dwellMs": 30000,
          "triggerEvent": "comments_dwell_30s",
          "oncePerSession": true
        },
        {
          "id": "idle_30s",
          "type": "idle_threshold",
          "idleMs": 30000,
          "triggerEvent": "idle_30s",
          "oncePerPage": true
        }
      ]
    }
  }
}

2. Add the expected journey

In the same schema, define journey.expectation.

You are describing the machine-checkable journey, not writing prose.

Use:

  • milestones for expected steps
  • successPaths for a fully successful flow
  • failureSignals for meaningful drop-off or risk signals
  • nextActionRules for what the operator should do next

Example:

{
  "journey": {
    "expectation": {
      "milestones": [
        {
          "id": "read_comments",
          "eventType": "comments_dwell_30s",
          "required": true
        },
        {
          "id": "click_primary_cta",
          "eventType": "cta_click",
          "required": true
        }
      ],
      "failureSignals": [
        {
          "id": "idle_after_comments",
          "eventType": "idle_30s"
        }
      ],
      "nextActionRules": [
        {
          "id": "recover_comment_dropout",
          "whenFailureSignal": "idle_after_comments",
          "action": "show_recovery_prompt"
        }
      ]
    }
  }
}

3. Publish the page

After you update the campaign structure, publish the campaign page. The published page uses the managed collector and the runtime tracking config compiled from your schema.

4. Send traffic to the page

Once visitors reach the published campaign page, the collector starts recording accepted page behavior events for that campaign session.

5. Open the admin customer-flow surface

Go to the authenticated admin app and open the customer-flow view for the selected handle. The Campaign Session Story card shows:

  • recent campaign sessions
  • accepted signal counts
  • the latest session state
  • milestone completion
  • deviations
  • next action
  • timeline
  • summary status

What the story means

Timeline

The timeline is the ordered list of accepted events for the session.

Examples:

  • page view
  • comments dwell trigger
  • CTA click
  • idle threshold trigger
  • conversion

Milestones

Milestones show whether the session completed the expected journey steps.

Possible states:

  • completed
  • missing

Deviations

Deviations explain where the session diverged from the expected path.

Common examples:

  • a required milestone was never reached
  • a failure signal was observed after a proof step

Funnel stage

The story currently groups the session into one of these states:

  • NEW
  • ENGAGED
  • ENGAGED_NO_CTA
  • CONVERTED

Next action

The next action is chosen from your configured rules. It is deterministic, not guesswork.

Examples:

  • show_recovery_prompt
  • reinforce_primary_cta
  • observe_next_step

How to know the feature is working

Use these checks:

  1. The campaign page is published through the managed 10x flow.
  2. The session count appears in the Campaign Session Story card.
  3. Accepted signal counts increase after page activity.
  4. The latest session shows a recent last accepted event.
  5. The story shows timeline items and milestone states.
  6. The summary status changes from missing to ready after summary generation.

If the story card stays empty:

  • check that the page has traffic
  • check that your schema actually contains tracking.behavior and journey.expectation
  • check that your tracked selectors exist on the live page
  • check that the page is a 10x-managed published page

Advanced use

Advanced operators can also read the feature through authenticated APIs:

  • GET /v2/handles/{handle}/campaigns/{campaignId}/sessions
  • GET /v2/handles/{handle}/campaigns/{campaignId}/sessions/{sessionId}/story
  • POST /v2/handles/{handle}/campaigns/{campaignId}/sessions/{sessionId}/story/summary
  • GET /v2/handles/{handle}/campaigns/{campaignId}/tracking-status

Current limitations

These are the main things still pending:

  • the operator summary may fall back to deterministic text if the optional model summary is not configured
  • summary generation is not yet handled by a separate async background job
  • the feature does not show a privileged overlay on the live public page
  • outbound delivery receipts are not fully surfaced in the tracking-status view yet
  • only 10x-managed published campaign pages are supported in v1

Start with one campaign page and one or two strong milestones.

Good first examples:

  • comments dwell + CTA click
  • pricing dwell + lead form start
  • FAQ dwell + checkout CTA click

Do not start with too many triggers. A smaller expectation model is easier to verify and easier to trust.

Updated Jun 19, 2026