Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
BedrockMission!

Learn More

View all

Sign in to view all badges

SAINT Campaign Tracking Codes (cid, cmpid, camp) - Alternate regex friendly format

Avatar

Avatar
Validate 1
Level 1
brandonl6179383
Level 1

Like

1 like

Total Posts

1 post

Correct Reply

0 solutions
Top badges earned
Validate 1
Boost 1
View profile

Avatar
Validate 1
Level 1
brandonl6179383
Level 1

Like

1 like

Total Posts

1 post

Correct Reply

0 solutions
Top badges earned
Validate 1
Boost 1
View profile
brandonl6179383
Level 1

23-06-2018

Hi All,

I've recently joined an organisation who are using reasonably complex campaign tracking codes, for example:

?cid=paid__GEN_BI_BRAN_CARE_DITO_INS_GEN_EX_20186_WA_GEN__p13836758146

The format of this code contains 13 regex match groups, delimited by 12 underscores (_). The issue I've found is this code is often full of mistakes, with additional underscores being added into match groups, matching groups containing no information, or matching groups being absent entirely.

The regex in Adobe's Classification Rule Builder is as follows:

paid__([^_]+)_([^_]+)_([^_]+)_([^_]+)_([^_]+)_([^_]+)_([^_]+)_([^_]+)_([^_]+)_([^_]+)_([^_]+)__p(\d{11})

which at first glance I find difficult to understand. Also, because it's relying on exactly 13 regex match groups delimited by 12 underscores, it will not match if the tracking code is different to this format.

URL Query String Alternative

I want to change the tracking code so it's both mistake resistant and regex friendly. The idea is to make a "pseudo query string" format, like you'd normally get on a URL (e.g ?name=ferret&color=purple). For example:

?cid=paid_1:GEN_2:BI_3:BRAN_4:CARE_5:DITO_6:INS_7:GEN_8:EX_9:20186_10:WA_11:GEN_12:13836758146

The regex in Adobe's Classification Rule Builder can then be setup as follows:

paid.*_1:([^_]+)(_)?.*

To match different parameters from the string, all you need to do is change the number (highlighted in red). In the rule builder the replace group will always equal $1. E.g.:

paid.*_1:([^_]+)(_)?.*    > $1 matches GEN

paid.*_2:([^_]+)(_)?.*    > $1 matches BI

paid.*_3:([^_]+)(_)?.*    > $1 matches BRAN

paid.*_4:([^_]+)(_)?.*    > $1 matches CARE

[...]

If a user enables a tracking code which doesn't exactly match the new format, the other parameters will still classify just fine. E.g.:

     ?cid=paid_1:GEN_2:BI

...will still match GEN and BI.

?cid=paid_1:GEN_2:BI_3:BRAN_4:CARE_5:DITO_6:INS_7:GEN_8:EX_9:20186_10:WA_11:GEN_12:13836758146_13:blah_14:moreblah

...will still match everything setup in your classification rules and ignore 13 and 14.

?cid=paid_1:GEN_2:BI_3:BRAN_4:CARE_5:DI_TO_6:INS_7:GEN_8:EX_9:20186_10:WA_11:GEN_12:13836758146

...will only break classification in 5, and not the entire key.

My question is can anybody see any issues with this? I've searched far and wide and haven't found anyone using this approach.

Kind Regards,

Brandon

Accepted Solutions (1)

Accepted Solutions (1)

Avatar

Avatar
Establish
Employee
hyderziaee
Employee

Likes

225 likes

Total Posts

465 posts

Correct Reply

222 solutions
Top badges earned
Establish
Coach
Contributor
Shape 1
Give Back 25
View profile

Avatar
Establish
Employee
hyderziaee
Employee

Likes

225 likes

Total Posts

465 posts

Correct Reply

222 solutions
Top badges earned
Establish
Coach
Contributor
Shape 1
Give Back 25
View profile
hyderziaee
Employee

23-06-2018

Brandon, this looks like an amazing solution to your problem.

Eventually you may want to make sure all the data is coming correctly, but this solution beautifully incorporates a great safety factor.

Hyder

Answers (0)