Tracking Macros

Use a tracking macro only when your landing URL template needs AON to place a value at a specific location. The available Partner-facing macros are {CLICK_ID} for click attribution and {PSEUDO_USER_ID} for a best-effort pseudonymous identifier.

Templates opt in explicitly

AON expands {PSEUDO_USER_ID} only when your landing URL template contains that exact macro. It is not automatically appended to a destination URL.

Configure the template

Add a macro where your landing page expects a URL-component value:

https://partner.example/landing?click_id={CLICK_ID}&visitor={PSEUDO_USER_ID}

You can use either macro more than once. Each occurrence receives the same value for that click. If your template has no {PSEUDO_USER_ID}, AON does not derive, persist, or deliver a Pseudo User ID for that redirect.

Macro	Use it for	How it is delivered
`{CLICK_ID}`	Per-click attribution and later conversion/postback matching	AON creates an `aci_...` public click ID after accepting the click. If this macro is absent, existing AON `aon_click_id` fallback behavior still applies.
`{PSEUDO_USER_ID}`	A best-effort, click-time pseudonymous identifier for a Partner landing page	AON uses a valid inbound `pseudo_user_id` first, otherwise follows the fallback rules below. It is not an account ID, authentication credential, or cross-device identity claim.

Pseudo User ID selection

An inbound pseudo_user_id is AON-owned input: AON selects the first valid, non-empty value and consumes all matching inbound parameters. “Consumed” means the value is not forwarded as a normal query parameter to your destination. It does not mean that AON erases existing click diagnostics.

When there is no valid explicit value and your template contains {PSEUDO_USER_ID}, AON derives a 32-character lowercase hexadecimal MD5 value:

MD5(UA bytes + canonical IP text bytes)

The normal path uses the original User-Agent byte sequence immediately followed by the canonical client IP text byte sequence: no separator, no salt, and no extra normalization of the User-Agent. This makes the value reproducible for the same normal inputs, but it is still only a best-effort pseudonymous value.

Weak-input behavior

For a normal aon.link redirect, a valid User-Agent or trusted client IP can be missing. To avoid merging many unrelated visitors under weak inputs, AON uses the available User-Agent bytes and/or canonical IP text bytes plus the current {CLICK_ID} bytes before calculating MD5. The result is click-scoped: it intentionally degrades to a value unique to that click, not a stable identifier across clicks.

Static Offerwall redirects use the trusted edge input contract and require both User-Agent and client IP. Their normal fallback therefore uses the regular MD5 formula above rather than the weak-input, click-scoped branch.

URL safety and redirect behavior

Macro values are URL-component encoded before insertion. An explicit Pseudo User ID containing &, #, %, spaces, or non-ASCII UTF-8 text remains one value; it cannot add query parameters or change a fragment boundary.

For Static Offerwall, the existing three-second deduplication window treats the effective Pseudo User ID as part of the click identity only when this macro is present. The same effective value can reuse the existing click chain during the window. A different valid explicit value creates an independent click chain so the redirect cannot return the first visitor's value. This does not change the normal redirect-template or campaign-query contract.

Persistence and privacy

When AON actually expands {PSEUDO_USER_ID}, the delivered value can be kept in click diagnostics such as macro_values and the final redirect URL. Normal redirect request URLs or parameters may also retain their existing diagnostic record. The value is delivered to the Partner whose template contains the macro.

Do not put direct identifiers or sensitive personal data in pseudo_user_id. The fallback is not a user account, a credential, a fraud decision, or a guarantee of anonymity. Use {CLICK_ID} for click attribution and retain the Partner-side consent, retention, and privacy controls appropriate for your integration.