Expand my Community achievements bar.

SOLVED

Using same value on tntId and thirdPartyId to deliver consistent experiences

Avatar

Level 2

Hi everyone,

 

We are using the Adobe Target server-side SDK to fetch experiences and we want to deliver a consistent experience across all devices/platforms for each client using thirdPartyId (if experience A was delivered, the next time it should deliver experience A)

 

The delivery api [https://developer.adobe.com/target/implement/delivery-api/ ] recommends to reuse the same sessionId for each thirdPartyId to get this behaviour.

 

const options = {
            id: {
                thirdPartyId: "VALUE"
            },
            execute: {
                mboxes: [{
                    name: "cta-poc",
                    index: 1
                }],
            }
        }
const response = await tClient.getOffers({request: options, sessionId: "2d81866d2d594121ab64fcb9318aa393"});

 

However, we have found that if we use the same value for the tntId and thirdPartyId. Adobe Target delivers the same consistent experience across all devices.

 

const options = {
            id: {
                tntId: "SAMEVALUE",
                thirdPartyId: "SAMEVALUE"
            },
            execute: {
                mboxes: [{
                    name: "cta-poc",
                    index: 1
                }],
            }
        }
const response = await tClient.getOffers({request: options});

 

I suppose this is not the best practice but could someone help us about this last approach? are there any downsides?

 

Thanks,

Ricardo

 

Topics

Topics help categorize Community content and increase your ability to discover relevant content.

1 Accepted Solution

Avatar

Correct answer by
Level 2

After more research we found the following:

 

- Does Adobe Target guarantee stickiness forever?

By default, it guarantees up to 14 days and it could be increased up to 90 days if the visitor profile is inactive for that period. Ref: https://experienceleague.adobe.com/docs/target/using/audiences/visitor-profiles/visitor-profile-life...

 

- Downsides of sending same value for both tntId and thirdPartyId at the same time to get stickiness

We achieve stickiness but reports are not accurate, when the same request is sent multiple times, the reports mark multiple visitors instead of 1 visitor.

View solution in original post

6 Replies

Avatar

Community Advisor

hi @RicardoDe  - same session-id is to be used for one session which should be specific for a single device/platform and lasting for 30 minutes. Session-ids should be generated after every 30 minutes.

 

For your use-case, using a consistent thirdpartyid across multiple platforms should be fine and thats the best practice. Could you please confirm whether you faced any challenges while using thirdpartyid?

Avatar

Level 2

Hi @Rajneesh_Gautam_ 

If we use sessionId + thirdPartyId during the first 30 min, everything is working as expected (we receive same experience). We know this is the recommended way(best practice) to go.

 

However, doing some tests we found (hack/bug/corner_case) that if we just use the same value for tntId and thirdPartyId, we are also getting the same experience as we are expecting.

Then, we would like to know if this approach (using same value for tntId and thirdPartyId) has any downsides (user tracking, profiling/segmentation, ....).

We know it is not the best practice but helps to avoid caching sessionIds.

 

Thanks,

Ricardo 

Avatar

Community Advisor

thanks @RicardoDe - this is an interesting finding. Creating parallels with how client-side implementation works, I believed having session-id is mandatory for Delivery-APIs, will try omitting it to understand the behaviour in more detail.

 

For the second part where you see expected behaviour while using same value for tntId and thirdPartyId, its worth asking the question to Adobe Engineering team as this implementation is a bit peculiar, and (as you have rightly asked) - may have some impact on audience-qualification + reporting.

 

Please share your findings here 

 

Regards

Rajneesh

 

Avatar

Level 2

Hi  @Rajneesh_Gautam_ 

We have raised the question (downsides on sending same value for both tntId and thirdPartyId to get stickiness) with support team and they are going to review it with Engineering team.

 

In parallel, do you know if just using the the thirdPartyId along with the same sessionId guarantees stickiness forever or adobe target could deliver different experience after time?

 

Example of the code:

const options = {
            id: {
                thirdPartyId: "VALUE"
            },
            execute: {
                mboxes: [{
                    name: "cta-poc",
                    index: 1
                }],
            }
        }
const response = await tClient.getOffers({request: options, sessionId: "2d81866d2d594121ab64fcb9318aa393"});

 

Regards,

Ricardo

Avatar

Community Advisor

hi @RicardoDe  - do you mean using same session-id all the time (even if the visitor is returning back after 30 minutes)?

 

Using same thirdPartyId with multiple session-ids works so I am hoping using single session-id should not have any issues as long as your entire reporting is visitor-based (and not visit based).

 

As you rightly said earlier, these are edge-cases and as not many people may have tried these (I certainly haven't), its always recommended to check with the Adobe Engineering team to avoid any issues. 

 

Regards

Rajneesh

Avatar

Correct answer by
Level 2

After more research we found the following:

 

- Does Adobe Target guarantee stickiness forever?

By default, it guarantees up to 14 days and it could be increased up to 90 days if the visitor profile is inactive for that period. Ref: https://experienceleague.adobe.com/docs/target/using/audiences/visitor-profiles/visitor-profile-life...

 

- Downsides of sending same value for both tntId and thirdPartyId at the same time to get stickiness

We achieve stickiness but reports are not accurate, when the same request is sent multiple times, the reports mark multiple visitors instead of 1 visitor.