Expand my Community achievements bar.

SOLVED

Channel overview report | Session refresh (internal) traffic over 20%

Avatar

Level 1

Attempted to set up the channel overview report for a hotel website (domain A) and its booking engine (third-party shopping cart, domain B) utilizing third-party cookies and common omniture report suite. 

Although both domains are added to internal URL filters and

- channel processing rules were set up based on what Adobe outlines (screenshot attached) 

- last-touch channel override was turned off for direct and session refresh (internal) channels

- confirmed that appmeasurement tracking is set up correctly and there is no re-direct on the landing pages

we have been struggling with around 20-25% last-touch session refresh (internal) traffic for more than a month now.

As a last resort,we reached out to our Adobe consultant who advised that our numbers are align with the trends what their experts have seen:

" — the 50% we confirmed for Session refresh + Direct traffic is the trend most experts have seen across different clients w/r to Adobe Analytics, but it will vary based on strength of a clients brand."

This puts us in a very weird situation as based on the channel overview report we can not tell where 20-25% of the website traffic comes from. 

Luckily we have other ways to report on channel performance but would have been super comfortable to use the channel overview report on a daily basis for first and last-touch results.

Any advice or best practices on this would be much appreciated! 

Thank you!

1 Accepted Solution

Avatar

Correct answer by
Former Community Member

We're running VisitorID v1.8, which was released 9/2016. The November release included v1.9, with some notes referencing cross domain issues that it fixed.

  • Fixed a bug that prevented the ID service from passing the Marketing Cloud ID (MID) across different domains. (MCID-215)

So you may be correct, however I'd expect more people reporting issues. FWIW, we are also running AppMeasurement v1.7, the most current version.

View solution in original post

5 Replies

Avatar

Level 7

Do you have anything which goes cross domain and do you use MCID service?

Avatar

Former Community Member

We've been seeing the same: an increase in the share of Session Refresh visits compared to all other channels. This began on or around 9/27/2016 and affects all report suites and locales. Digging into this, it appears that most of these visits with newer browsers -- most specifically Safari 10.0 and 9.0 (2 of the 3 top browsers we currently see). We have not identified a root cause or fix at this point, but will share when we do.

 

juditb_26, Can you break down your visits by browser and see if Safari is unduly contributing to your Session Refresh numbers? 

Avatar

Former Community Member

Yes, we use the MCID and have some (not many) cross domain links. Nothing that has changed recently/around that timeframe. And cross-domain wouldn't explain the browser specific issues, would it?

Avatar

Level 7

potentially yes - Safari is particularly bad for 3rd party cookies which are needed when doing cross domain. If you're using an older version of MCID which has the short time out and no support for cross domain then I wouldn't be surprised if this is the issue, take a look at your entry pages for session refresh and see if it's cross domain. If it is then i'd recommend using the Append Visitor ID Function - https://marketing.adobe.com/resources/help/en_US/mcvid/mcvid-appendvisitorid.html

We had the exact same issues with visitor ID, very high session refresh caused by cross domain and the visitor ID timeout being too short. When we increased the visitor ID timeout time we noticed a drop in session refresh and then when we implemented the Append Visitor ID function which appends the visitor ID to the cross domain URL it dropped even further to within acceptable levels.

Avatar

Correct answer by
Former Community Member

We're running VisitorID v1.8, which was released 9/2016. The November release included v1.9, with some notes referencing cross domain issues that it fixed.

  • Fixed a bug that prevented the ID service from passing the Marketing Cloud ID (MID) across different domains. (MCID-215)

So you may be correct, however I'd expect more people reporting issues. FWIW, we are also running AppMeasurement v1.7, the most current version.

The following has evaluated to null or missing: ==> liqladmin("SELECT id, value FROM metrics WHERE id = 'net_accepted_solutions' and user.id = '${acceptedAnswer.author.id}'").data.items [in template "analytics-container" at line 83, column 41] ---- Tip: It's the step after the last dot that caused this error, not those before it. ---- Tip: If the failing expression is known to be legally refer to something that's sometimes null or missing, either specify a default value like myOptionalVar!myDefault, or use <#if myOptionalVar??>when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: #assign answerAuthorNetSolutions = li... [in template "analytics-container" at line 83, column 5] ----