Measure adjacent steps before describing a customer journey

I maintain this Actor. This is an AI-assisted technical walkthrough checked against the installed source contract.

An ordered list can support an exact statement about adjacency without supporting a statement about a customer journey. If a submitted sequence says discover, compare, select, purchase, it contains three directed adjacent transitions. It does not establish who took those steps, how long they took, or whether the list describes a real person at all.

US Brand Signal Sequence Transition Analyzer accepts one to 100 uniquely identified sequences. Each sequence contains two to 30 bounded opaque step IDs in buyer-declared order. The Actor builds a deterministic report of directed adjacent-transition counts. It does not attach a time model or identity model to the identifiers.

Count the example before running anything

The three synthetic sequences below are discover/compare/select/purchase, discover/compare/purchase, and discover/select/purchase. Their lengths are four, three, and three. They therefore contribute three, two, and two adjacent transitions, for seven total occurrences.

Discover to compare occurs twice. Select to purchase occurs twice. Compare to select, compare to purchase, and discover to select each occur once. Discover to purchase is not an adjacent transition in any of the three sequences, even though purchase appears later than discover in each list.

That distinction matters when a report gets relabeled as a funnel. A sequence transition table counts neighboring entries. A funnel conversion calculation needs a declared population, entry criteria, identity stitching rules, timing boundaries, and an outcome definition. Those facts do not appear merely because a token happens to be named purchase.

Decide how repeated steps should be represented

If an upstream export contains repeated steps, inspect why before counting. A repeated observation may be a meaningful return to a state, or it may be a collection duplicate. The Actor's deterministic calculation cannot choose the correct interpretation of the upstream event stream. Preserve the original ordering rule in the review notes.

Use stable sequence IDs so a reviewer can trace a row back to its source export. Avoid concatenating two unrelated sequences into one list: doing so introduces a new boundary transition that neither original sequence contained. Splitting a sequence can remove a boundary transition for the same reason.

A practical use is comparing process annotations before a taxonomy change. Prepare a small authorized export, calculate its transitions, then manually inspect the source records for the most common pairs. A report makes that selection reproducible while leaving process interpretation with the analyst.

Keep the normalized input and report digests with the upstream extraction version. Reordering sequences as whole records should not be used to imply a new business event; changing the order of steps inside a sequence changes the observation being measured.

The review conclusion should say exactly which transitions were observed in which submitted sequences. A claim about user intent, elapsed time, or business causality requires additional evidence beyond these adjacent counts.

Input and execution boundary

Save this workflow-specific contract example as input.json. This is a synthetic contract example for the workflow described above; it does not assert a real observed business event.

{
  "schemaVersion": "1.1",
  "sequences": [
    {
      "sequenceId": "journey-001",
      "stepIds": [
        "discover",
        "compare",
        "select",
        "purchase"
      ]
    },
    {
      "sequenceId": "journey-002",
      "stepIds": [
        "discover",
        "compare",
        "purchase"
      ]
    },
    {
      "sequenceId": "journey-003",
      "stepIds": [
        "discover",
        "select",
        "purchase"
      ]
    }
  ]
}

A deliberate cloud execution can use the following asynchronous request. It creates a new run and may incur charges; this walkthrough did not execute it.

curl --request POST \
  'https://api.apify.com/v2/acts/zinin~us-brand-signal-sequence-transition-analyzer/runs?build=0.2.2&timeout=180&maxTotalChargeUsd=0.10' \
  --header "Authorization: Bearer $APIFY_TOKEN" \
  --header 'Content-Type: application/json' \
  --data-binary @input.json

Save the returned run ID. Check that existing run before retrying after a client timeout, then inspect its terminal status, Dataset, and KVS OUTPUT. A timeout in the caller does not cancel a server run. The charge ceiling bounds the request; it does not guarantee delivery or remove the start event. The build selector pins the observed build number, while the run's actual build ID should be retained for provenance.

Price and reproducibility

On 19 October 2026, the observed FREE-plan rates are $0.005 for the automatic start event and $0.01 per complete delivered report. The platform can count start events according to allocated memory. Other subscription tiers differ. Verify the current Actor page before purchasing a run; optional external services, where enabled, are separate.

This article uses the installed 0.2.2 source contract and saved public input shape, checked on the stated date. The arithmetic examples are explanatory, not fresh cloud acceptance, customer activity, or evidence of revenue. Preserve your input, actual build ID, observation boundary, and terminal receipt when adapting the workflow.