If a hit doesn't pass Paid Search will it skip to Natural Search processing rule?

[aris-signet]

We're seeing strange data coming through for Last Touch Channels. After correcting how the referring URL was passed into link tracking, we saw a surge in Natural Search as Last Touch, however the vast majority of this surge has a Tracking Code and/or query param that should pass an upstream rule.

Assuming that our order is:

1. Paid Search (any)
   1. Matches Paid Search
   2. Tracking Code contains 'SEM'
2. Display
   1. Tracking Code contains 'ABC'
3. Natural Search (any)
   1. Matches Natural Search
   2. Tracking Code contains 'SEO'

And if the hits have referrer='www.google.com' and Tracking Code='ABC', we'd assume that it would be labeled as "Display" because of the order, but these ends up going into the "Natural Search" bucket. 

Has anyone run into this before or any thoughts? Our next step is change the order, but eager to hear if anyone has tested this situation.

Thanks!

 Natural Search definition: https://experienceleague.adobe.com/docs/analytics/admin/admin-tools/manage-report-suites/edit-report...

[yuhuisg]

Can you elaborate further on what had been done for correcting how the referring URL was passed into link tracking?

[Jennifer_Dungan]

Right, based on that description... Tracking Code='ABC' should land in Display... but maybe there are some specifics of the rules that aren't fully disclosed here?

I agree with @yuhuisg I think we need to dig a little deeper into how the data is being processed to understand why it's bypassing the second bucket.

[aris-signet]

The majority of link tracking calls weren't passing the page or referrer URLs, we had to turn on the automatic collection in Web SDK Extension.

I think this might be a red herring, limited data made our heads spin. It turns out that the instances of a specific custom link with last touch Nat Search started to increase in the days before we saw the Visits increase. There could have been a third party updating their custom link call because this would not be affected by the update to the Web SDK extension. 

The deployment we made likely did add to the increase, now the rest of the custom links will have additional data for channel processing. We'll be looking to turn off the custom link in question just to be sure! As I'm still confused with some of the data, prior to the days in question, but I'll follow up when I know more!

Thank you @yuhuisg and @Jennifer_Dungan 

[aris-signet]

@yuhuisg @Jennifer_Dungan So both deployments likely had an impact, and both deployments were only for custom links, and nothing seems to make sense.

We see one sample user (slightly different scenario than my first example, this is Paid Search switching to Natural Search), who entered via a Google SEM link, the Entry URL shows the 'cid' parameter with the same value that is populated in Tracking Code.

For their first 8 hits, they were properly bucketed into the Paid Search channel. 

- Tracking Code shows the CID

- Search Engine - Paid = Google

- Search Engine - Natural = unspecified

Then on the 9th hit, a custom link, it switches to Natural Search

- Tracking Code shows the CID

- Search Engine - Natural = Google

- Search Engine - Paid = unspecified

The custom link did not pass a new Tracking Code and did not contain an external referrer, and occurred within a minute of the previous hit, a page view.

Then when the user ultimately converted, LTC for the conversion is set to Natural Search.

We're seeing this happen for about 10% of our visitors, who are about 75% mobile vs desktop, and even distribution between Chrome and Safari.

Processing rules, also the Tracking Code that is logged for the visit begins with 'SEM-'
Any thoughts are appreciated!

[Jennifer_Dungan · Accepted solution]

Tracking Code generally has a different attribution than Marketing Channel  (tracking code defaults to 7 days, Marketing Channel default to 30 Days)

Is your Tracking Code just based on CID? If so, you don't need both rules... I would just use the CID variant to avoid potentially attribution conflicts.... 

Also, Natural Search shouldn't have any CID values on it... I would expect you are missing a lot of Natural Search values by specifying that it must have a CID value.... Natural Search are pages that Google crawls from your site and links to... they shouldn't ever have cid values.... The fact that you have any traffic to Natural Search tells me that Google is indexing non-canonical URLs, which is bad, because you will have multiple versions of the same URL with different parameters fighting for relevancy against themselves.... Paid Campaigns, because they are specifically designated in your Google Ads Account, shouldn't have issues.. but Natural Search is a different beast....   (ah quick update here.. you have "ANY" not "ALL" rules in your screenshot, that is how your Natural Search is working.. but again, you shouldn't have CID on Natural Search at all, so you should consider setting your Channel value to something like "Search Engine" as your Marketing Channel detail for Natural Search will be mostly no value ever)

But in your Scenario:

• Hit 1
  • Tracking Code shows the CID
  • Search Engine - Paid = Google
  • Search Engine - Natural = unspecified
    • Resulting in your Tracking Code picking up your campaign, and your Marketing Channel picking up Paid Search
    • Note that your Marketing Channel Detail should also contain your Tracking Code values (because you have "set the Channel's value to Tracking Code")
• Multiple Hits will happen
• User either backs out to Google, or does a second Google Search, this time clicking on a non-paid result
  • Natural Search overrides Paid Search (this is now the last touch)
  • Tracking Code shows the CID, yes, because Tracking Code has a 7 Day attribution (and you are still technically in the same Visit)... a value of "" does not override the previously set value... if it did, your Tracking Code would never be able to properly maintain it's attribution, as the next hit where it's not set would override it
  • Search Engine - Natural = Google (also correct, this is last touch Marketing Channel)
  • Search Engine - Paid = unspecified
    • In this case, your Marketing Channel is overwritten by Natural Search as the last touched channel.... 
    • Tracking Code will NOT override, as no value has been set to that dimension to override with, and it shouldn't.. since Natural Search does not have tracking code values
    • This is why you should be pairing your Marketing Channel with Marketing Channel Detail.... this is the "Channel Value" that you are setting in your rules... it follows the same attribution rules

Basically you are running into scenarios with different attribution and trying to mix them, and that is going to cause data mis-matches and cause confusion.

[aris-signet]

Thank you @Jennifer_Dungan we've finally rooted out the issue. 

In my previous experiences with AA, we've relied on using Props/eVars in our marketing processing rules, and not the presence of query parameters in the page url. I may have forgotten or never been aware of the fact that Custom Links DO NOT have the Page URL available in Marketing Processing rules (as noted here: https://experienceleague.adobe.com/docs/experience-cloud-kcs/kbarticles/KA-15760.html?lang=en#) 

This means that none of our processing rules which look for the presence of a query parameter will work! This results in the fact that all custom links fired on the entry page will cause LTC attribution to fall into organic for any of our paid channels, because all they have available is the Referring URL.

The final result is that the best practice for Marketing Channel Rules is to use either Tracking Code or a prop/evar to track paid and organic channels ensure that Custom Links don't force mis-attribution because they lack the ability to read the current Page URL. 

For Adobe folks, this is definitely something to call out on the more general pages about Marketing Channel processing rules, it was frustrating only to find these pages calling out the fact that Custom Links do not use Page URL in processing. Big gap in documentation, but hopefully others will see this post!

[Jennifer_Dungan]

You shouldn't need to be looking at your custom links.... Marketing Channels are about entries to your site.. once a custom link is triggered, the user is already on your site and should be attributed to a channel....

[aris-signet]

Haha, well that was what I thought! That's why I was running in circles with this logic and the clickstream logs.

Shouldn't is the word but it turns out in the case of using the Web SDK, Custom Links are overwriting LTC mid-visit and even on the same page as a page view. We've found instances where on one page the user had 3 LTCs because there were two Custom Links and a Page View that fire, and each passed/uses a different set of attributes and so passed/failed various rules in the waterfall.

Overall we have isolated a set of specific scenarios and have reproduced the issues. Once we disabled passing the Referrer URL in Custom Links, we saw the volume of multi-LTC channels in a single visit decrease. 

Next step is then adding rules to duplicate query param logic with a Tracking Code version to cover all Custom Links (which don't use Page URL in logic), since the Tracking Code is evaluated only at a hit level. 

[Jennifer_Dungan]

Hmm that sounds like a tracking issue.. I would be more concerned that the WebSDK isn't working as expected... 

But yes, removing the Referrer URL in your custom links is a good first step... since they don't need / shouldn't have that anyway

Looks like you are well on the way to sorting this out. Good luck!

[yuhuisg]

Can you share the gist of your Web SDK tracking for pages and custom links?

Your experience with Web SDK doesn't gel with mine.