Expand my Community achievements bar.

Activity level option to use the 3rdPartyID or not to prevent experience switching that occurs after updating the 3rdPartyID on sign in

Avatar

Employee

2/8/19

Wants flexibility to do cross device targeting for some experiences and to not  have to do it for all as in certain cases they don't won't experience switching to happen .

Ref: Real-time profile syncing for mbox3rdPartyID

3 Comments

Avatar

Level 1

2/8/19

Tests run in authenticated spaces where the 3rdPartyID can be reliably set for all visitors can benefit from consistent test experience delivery across a visitor't devices.

However, tests run on pages outside of the authenticated experience, such as homepage, where a large number of visitors are not recognized at the time of the pageview, but also have a large percentage of those visitors who go on to sign in will can see a very high number of visitors switching experiences on their next hit of that test page.

This fundamentally breaks test analysis as any conversion can not be correctly attributed to one test experience or another.

The ability to optionally use 3rdPartyID on a per activity basis would be one way to prevent this.

Adding reporting for "tainted" visitors (those with hits in multiple experiences) to be able to see the number of visitors counted in multiple experiences and either exclude them from analysis or add more options for how their conversions should be attributed may also help with this issue.

Avatar

Level 2

3/13/23

Even better if we could take this one step further, it would be great to set the randomization unit:

  1. Visitors (default)
  2. Profile Attribute (e.g. market ID)
  3. Devices
  4. Sessions
  5. Hits

Avatar

Level 2

11/25/24

Today, you snapback to your first experience when you authenticate. An alternative solution would be to allow the current experience to override the the profile rather than returning to the first experience. This solution would maintain the current experience. This would be configurable by campaign.

 

Today:

Known User 1 w/ Device 1: Test A -> Anon User 1 w/ Device 2: Test B -> Known User 1 w/ Device 2: Test A -> Known User 1 w/ Device 1: Test A

 

Proposed when enabled:

Known User 1 w/ Device 1: Test A -> Anon User 1 w/ Device 2: Test B -> Known User 1 w/ Device 2: Test B > Known User 1 w/ Device 1: Test B