Unreadable tracking value in postbacks (auto-corrected)
A network's postbacks had a correct click ID, plus a dyn value we could not read. We ignored dyn, matched the click by its ID, and counted the conversion.
What it means
A postback to Routy can carry two values that point to the click:
clickId: the long click ID Routy created for the visit, for examplea1b2c3d4-e5f6-7890-abcd-ef1234567890.dyn: Routy's shorter tracking value for the same click, for exampleRT10000.
clickId was fine. dyn held something that is not a Routy tracking value. Because clickId was enough to find the click, we dropped the unreadable dyn and recorded the conversion. The click's own tracking value is still kept on the conversion, so no data was lost.
Why it happens
- The network sends its own value in
dyn, for example its transaction ID or a numeric sub-ID. - The placeholder in
dyn=is not one the network fills, so it arrives as typed, for example{tracker}orsubid1. dyn=was added to the postback URL by copying a setup from another network.
What you can do
Your conversions are being counted, so this is not urgent. To stop the issue coming back:
- Open the issue's details and copy the example request. Look at what follows
dyn=. - Sign in to that network and open its postback settings for the account named in the issue.
- Either remove
dyn=...from the postback URL, or change its placeholder to the sub-ID that carries Routy's tracking value. With a workingclickId,dynis not needed. - Save.
When it clears
It closes by itself 3 days after the last postback with an unreadable dyn. You can also press Resolve once you have fixed the network's settings. If another one arrives, it opens again.