Conversion Path Brief: What the Contractor Needs Before Work Starts

A conversion path brief is the document a customer writes for the party that will build or change the measurement path: click on the ad, event in the source system, mapped event, destination in the advertising account. It is not a scope of work and not a field specification. It is an input inventory, and its rule is short: every value the receiving system will ask for gets answered before that system is touched, and every credential stays outside the document.

A brief should expose missing prerequisites before implementation: the destination action, the source event and the fields that connect them. Use the five input sets below as a checklist, then verify the requirements of each named receiving system.

What a Conversion Path Brief Fixes Before Work Starts

Way2 publishes the same list as the data it asks a customer to prepare, and it works as a skeleton precisely because it names no secrets:

Read as a brief, those five sets describe the path stage by stage; they do not close it. The page offers them as what to prepare, while its own next step is mapping one real conversion path, and that mapping is where the key binding a click to a join gets found. Landing URL is where the click lands and what identifiers still travel with it. Current route is the transport the bot already uses. Postback format is how the source reports a downstream outcome. Event names decide what the path is called at each end. Destinations decide who receives the mapped event at all. Two more items belong in the document because the list implies them: where credentials live, and what counts as accepted.

One boundary holds it together. The records a path keeps "do not promise attribution or bidding outcomes inside an ad platform", so a conversion path brief that promises an attribution result has misread its own purpose. What the brief pays for is a path that can be assembled from agreed fields.

The Five Mandatory Inputs and What Each One Unblocks

The five rows above define the inputs for a conversion path brief; the route and postback format need particular detail. A route written as "we have a bot" is not an input: in the route's own registry a click is bound to the invite issued for it, so the field the bot can actually show is the join update with its invite_link, not the raw advertising click identifier, and that binding has to be written into the brief before anything downstream is. A webhook that answers a delivery attempt with a non-2xx status keeps getting retried until the sender decides to "give up after a reasonable amount of attempts", behaviour the brief should expect rather than discover. A postback written as "we send status" is not a format either. Around subid and status sit a transaction id, a payout, a currency and up to thirty click-update parameters, and those names differ per tracker, so the field set decides whether an amount can be tied to the right click at all. The receiving shape is published rather than improvised: the tracker spells its incoming URL IP/postback-key/postback?subid=REPLACE&status=REPLACE&payout=REPLACE, so a conversion path brief quotes the documented example instead of re-deriving a macro syntax of its own.

The five sets above name the stages; the skeleton below has to name what joins them, because a brief that lists systems without the key between a click and a join describes three disconnected products. Two lines carry that key: the brief states which landing-side system stored the click against the invite it issued, and which system answers the lookup when the deposit arrives, because a join nobody can look up afterwards is not a binding. Anything that authenticates a request is a placeholder by design.

# conversion path brief - hand over the shape, never the value
path_id: "tg-deposit-2026q3"
observed_from: "2026-09-10"
landing:
  url: "https://example-landing.test/of/2117"
  click_parameters_surviving_redirect: ["gclid", "subid"]
route:
  bot_owned_by: "customer"
  transport: "webhook"
  admin_in_channel: true
  subscribed_update_types: ["message", "my_chat_member", "chat_member"]
postback:
  source_system: "Keitaro"
  # the tracker's documented receiving form, with the values substituted by the sender;
  # the brace form {subid} is the page-side Postback Pixel substitution, documented to work only on index.html or index.php
  url_shape: "https://tracker.test/<POSTBACK_KEY_WITHHELD>/postback?subid=REPLACE&status=REPLACE&payout=REPLACE&currency=REPLACE"
  click_field: "subid"
  status_field: "status"
  # the final list comes from the partner agreement; both values below are documented tracker types, and an unknown status is ignored unless the tracker is trained on it
  status_values_allowed_to_send: ["deposit", "rejected"]
correlation:
  # agreed while mapping one real path, then written into the brief and signed with it
  landing_click: "gclid or subid as the landing stores them"
  invite_issued: "the unique invite returned for the route bound to that click"
  mapping_stored_by: "which landing-side system keeps acquisition identifiers against the invite issued from them, named in this brief"
  join_event: "chat_member update: a ChatMemberUpdated carrying invite_link"
  deposit_lookup: "which system answers at deposit time whose click this join belongs to"
  partner_call: "subid echoed back on the deposit postback"
  join_key_carried: "yes"
event_mapping:
  google_conversion_action_name: "<agreed ConversionAction name>"
  meta_event_name: "<agreed Meta event name>"
destinations:
  - platform: "google_ads"
    account: "123-456-7890"
    action_exists: true
    import_method: "server_click_upload"  # server-side upload of click-based conversions
    role: "primary"
credentials_policy:
  tokens_in_this_document: "none"
  handover: "scoped grant per system, issued by the owner, revocable"
  consent_statement: "permission to share conversion data with each destination confirmed by the owner"
acceptance:
  sent: "outbound log line with destination and response"
  accepted: "receiver response plus its own counters"
  counted: "receiver report for the named action and window"
  not_in_scope: "attribution and bidding outcome"

Credentials Stay Out of the Brief Text

Start from the receiving side rather than from caution. A tracker's documentation describes the postback address as containing the server address, a postback key used for security and request authentication, and the conversion parameters. A working postback URL contains a credential. Never paste the live URL or key into a ticket; put only the URL shape with a named placeholder in the brief, and share the actual value through the owner-approved secret channel.

The same logic covers the rest of the path. A bot token authenticates everything the bot can do, and the brief needs only the transport and the subscribed update types; if an integration must prove a webhook is its own, the documented mechanism is a secret token sent in a request header, which is configuration rather than text. Destination API tokens belong to the account owner and get issued per integration, and the practice of keeping identifiers and tokens out of third-party hands is documented for pixels in the Facebook pixel id and access token guide. For a customer-hosted integration, record where credentials will be kept, who can use them and how access will be revoked; confirm those boundaries in the agreement.

Permission is the one item people confuse with a credential, and it must not be omitted. For Google Ads imports, confirm permission to share conversion data through account-level default consent settings or the consent field on each imported conversion or user-data payload. That is a statement an owner signs, not a key. The Keitaro S2S postback setup walkthrough shows how the parameter shape looks in a real admin panel, which is the concreteness a brief should aim at without live values.

Four Acceptance Lines Instead of One Sign-Off

A single "events are firing" sign-off is where the customer loses the argument later, so the conversion path brief splits it into four lines with separate owners. The service FAQ states the split outright.

The fourth row is the one reviewers miss, because nothing a customer writes can oblige a platform to attribute a conversion. A second trap sits beside it: two delivered requests and two counted conversions are different claims, which is why counting gets its own artifact instead of inheriting the delivery log. Proof strength per observed event is laid out in Telegram conversion proof levels.

Brief Defects, Their Evidence and the Next Test

Four artifacts sit next to a conversion path brief and stay outside it. Field-level event schemas are a separate contract: which key is required, what each type means, what deduplicates. Ownership boundaries between source, router and destination form another document, deciding who retries and where responsibility transfers. Whether a source can emit anything at all is a discovery question that precedes the brief, and pushing one event into several destinations to read each answer is an acceptance test that follows it. Fold any of those in and the document stops being checkable, which is its only real property. The same line sorts the tests in the table above: each one closes on an artifact the document can show before work starts, and a check that needs a running incident to observe anything belongs to the pages named below, not here.

After the build the same pages work in another role: when a postback stops arriving, postback troubleshooting starts from the parameter names already recorded here. For a route that exists and needs no new path, the shorter tracking audit input checklist collects what an audit asks for, and standard events mapping settles naming once the path works.

Sources