Home Dynamic QR Source Routing

Source Routing

The campaign tag picks the destination, not just the row in the report.

NORTH LINE put the same code on the parcel card and in the follow-up email. In the channel review both arrive as one number, and the card is the cheaper line to cut.

The scan is tagged

The rule engine

ScanEvery scan enters hereTraffic sourceutm_source · Parcel insert · Em…utm_source · Parcel insert · Email1Parcel insertParcel insert2EmailEmailEveryone elseEveryone elsePost-purchase pagePost-purchase pageexample.com/unboxingexample.com/unboxingReorder and loyaltyReorder and loyaltyexample.com/reorderexample.com/reorderProduct pageProduct pageexample.com/productexample.com/product

What the scanner gets

Post-purchase page

The printed card, opening a page written for somebody holding the product. The tag decided the destination, not just the row in the report.

The rule reads utm_source here, and can read utm_medium, utm_campaign or the referring host instead. The tag is recorded in the analytics as well, but this is the rarer half: it selects the destination rather than only labelling the scan afterwards.

Get this wrong and print keeps arriving as "direct" in the channel review, which is the meeting where the insert gets cut. The cards are already in the boxes.

no subscription · pay per scan · nothing to cancel

Print keeps arriving as "direct", and direct is the cheapest line to cut

The same code often lives in more than one place: on the parcel insert, in the follow-up email, on a poster. When they all resolve identically, the channel review sees one number and print gets no credit for any of it.

  • One short link in two channels reports as one channel.
  • The insert and the email want different pages, and the code can only hold one.
  • Tagging the URL tells you where a scan came from afterwards, but changes nothing about what the scanner sees.
  • Print is the channel with the weakest attribution story, so it is the first line questioned.

What NORTH LINE tagged, and what changed because of it

  1. Pick the field to read

    The rule reads utm_source by default, and can read utm_medium, utm_campaign or the referring host instead. One field per rule.

    { "field": "utm_source" }
  2. Group the values that share a destination

    Groups are matched in order, case-insensitively after trimming, because tags arrive in mixed case from both the network and the person who wrote them.

    [{ "name": "Parcel insert", "values": ["insert"] }]
  3. An untagged scan takes the default

    Somebody typing the short URL, or a tag stripped on the way, means no signal and therefore your default. Which is why the default has to be a page you chose deliberately.

What one code does across two channels

  • The tag chooses the page source

    Not only a label in the report afterwards. The scan from the insert can open something written for a person holding the product.

  • Four fields to route on

    utm_source, utm_medium, utm_campaign, or the referring host when there is no tag at all.

  • Print separated from email

    The same artwork in two channels stops collapsing into one number, because it stops resolving to one page.

  • Recorded as well as routed

    Campaign source and referrer are both analytics dimensions, so the split shows up in the reporting too.

  • Composes with the rest

    Source then country is a common pair: the channel decides the page, the market decides which version of it.

  • One rule, 5 credits per change

    A source rule is 5 credits per change, and the scans it routes are 1 credit each.

Questions

Do you pass my UTM parameters through to the destination?

Not on a regular dynamic link. The redirect sends the scanner to the destination you stored, unchanged. UTM parameters are read as a routing signal and recorded in your analytics, but they are not appended to the outgoing URL. The exception is a GS1 Digital Link, where the standard requires the query string to be passed on and we do.

What is the difference between routing on a tag and tagging a link?

Tagging tells you afterwards where a scan came from. Routing on the tag changes what the scanner sees. The second is the rarer half, and it is what this rule does.

Which fields can it read?

utm_source, utm_medium and utm_campaign from the query string, or the referring host. One field per rule, so routing on two of them means two rules.

What happens to a scan with no tag?

It takes your default destination. That covers somebody typing the short URL, a tag stripped by an email client, and any value you did not group.

Can I set this up through the API?

No. Routing rules are built in the browser and the flow engine is not reachable from the API today. Creating and updating the codes themselves is, so a bulk run is scriptable even though its routing is not.