Target API implementation

[_Lukasz_]

We implemented Target API in our server-side application (it handles the cross-sell module e.g. in checkout). We were not able to find a straightforward way to generate new visitor ids so we are relying on an ECID that is generated in storefront by Visitor ID Service implemented through Launch. As a result, we are able to test on visitors who had at least one page view before entering a test.

I have 2 questions:

1) Do you see any flaws in the implementation described below that could have unwanted consequences (e.g. double visitor counting)?

2) How can we generate a valid tntId, sessionID and ECID fully server-side?

1. Retrieve tntId and sessionID from the mbox cookie

Example:

session#2c8f32c1f6544dd5a15360f457f31043#1583507820|PC#2c8f32c1f6544dd5a15360f457f31043.26_0#1646751083

2. Retrieve marketingCloudVisitorId from the AMCV_xxx%40AdobeOrg (this is our org id cookie) cookie

Example:

1585540135%7CMCIDTS%7C18328%7CMCMID%7C61203425459504369920807087607432177946%7CMCAAMLH-1584104968%7C6%7CMCAAMB-1584104968%7C6G1ynYcLPuiQxYZrsz_pkqfLG9yMXBpb2zX5dvJdYQJzPXImdj0y%7CMCOPTOUT-1583507368s%7CNONE%7CMCSYNCSOP%7C411-18335%7CvVersion%7C4.4.0

3. Make a server call to Adobe Target (if any of the elements from 1 or 2 is not available, don’t make the call)

https://{client}.tt.omtrdc.net/rest/v1/delivery?client={client}&sessionId={{sessionID e.g. 2c8f32c1f6544dd5a15360f457f31043}}

Body:

{
      "context": {
        "channel": "web",
        "address" : {
          "url" : "{{url}}"
        }
      },
      "experienceCloud": {
        "analytics": {
          "logging": "client_side"
    	}
      },
      "id": {
        "marketingCloudVisitorId" : "{{marketingCloudVisitorId e.g. 61203425459504369920807087607432177946}}",
        "tntId": "{{tntId e.g. 2c8f32c1f6544dd5a15360f457f31043.26_0}}",
        "thirdPartyId": "{{account id e.g. 0a9bc3d735014eb299dc057a8835e6ae}}",
        "customerIds": [{
          "id": "{{account id e.g. 0a9bc3d735014eb299dc057a8835e6ae}}",
          "integrationCode" : "cust_attr_acctid",
          "authenticatedState" : "authenticated"
},
        "execute": {
        "mboxes" : [
          {
            "name" : "CROSS-SELL-1722",
            "index" : 1
          }
        ]
      }
}

4. Retrieve tnta payload from the Target API response

Example tnta (execute → mboxes → analytics → payload → tnta): 265749:0:0|2,265749:0:0|32767,265749:0:0|1,266209:2:0|32767,266209:2:0|1

Example response:

{
    "status": 200,
    "requestId": "897f9a48-5654-4d21-a324-40d32b9833d2",
    "client": "{{client}}",
    "id": {
        "tntId": "2c8f32c1f6544dd5a15360f457f31043.26_0",
        "marketingCloudVisitorId": "61203425459504369920807087607432177946"
    },
    "edgeHost": "mboxedge37.tt.omtrdc.net",
    "execute": {
        "mboxes": [
            {
                "index": 1,
                "name": "CROSS-SELL-1722",
                "options": [
                    {
                        "content": {
                            "default": false
                        },
                        "type": "json",
                        "responseTokens": {
                            "experience.id": "0",
                            "activity.name": "{{activity name}}"
                            "activity.id": "265749",
                            "experience.name": "Experience A",
                            "geo.domainName": "{{domain name}}"
                            "offer.id": "596363"
                        }
                    }
                ],
                "analytics": {
                    "payload": {
                        "pe": "tnt",
                        "tnta": "265749:0:0|2,265749:0:0|32767,265749:0:0|1,266209:2:0|32767,266209:2:0|1"
                    }
                }
            }
        ]
    }
}

5. If tnta exists, make a request to Data Insertion API (make sure we use the mid parameter)

https://{{client}}.sc.omtrdc.net/b/ss/{{report suide id}}/0/CODEVERSION?pe=tnt&tnta={{tnta payload e.g. 265749:0:0|2,265749:0:0|32767,265749:0:0|1,266209:2:0|32767,266209:2:0|1}}&mid={{marketingCloudVisitorId e.g. 61203425459504369920807087607432177946}}

[josejr19]

@_Lukasz_ I too had similar issue with ECID not being generated from the server side visitor id service. I opened a defect about this back in 2019 and looks like still not resolved.

https://github.com/adobe/target-nodejs-sdk-samples/issues/7

As for your approach, this should work fine, my only question is why use the data insertion api when you can just take the same information and deliver it to the front end and send it along with the data you send on the client side? If you look at the reporting for page hits to the segment that is getting the a/b test in adobe analytics and then compare it to the segment based on the data sent in using the data insertion API there will most likely be a delta similar to what you can expect with an A4T implementation.

Hope this helps!

[_Lukasz_]

@josejr19 - thank you for your response.

"why use the data insertion api when you can just take the same information and deliver it to the front end and send it along with the data you send on the client side?"

I'm not sure how you suggest to do that exactly but I assume that there would have to be some work done on the client-side. If that is the case, we want to have 100% of the implementation on the server-side so each team responsible for the server-side piece can implement the whole flow independently, without involving client-side teams.

[josejr19 · Accepted solution]

@_Lukasz_ The idea is that you would just pass to the front end the activity name, experience name, and any additional data needed. Then in the beacon call to Adobe Analytics, you would pass the information in as well as evars. This means you need to have evars available in Adobe Analytics and also can pick up the data via Launch. Since you want to do this server side, a possible option would be to add into the initial page mark up server side the experience name/activity name meta data as an object in the head of the markup. In Adobe Launch you would grab the data and send it to Adobe Analytics on the front end. The only front end work would be technically via Launch and that would be to pick up the data from Target, I am not sure if that is a client side team in your company. 

In reviewing your approach again, should I be assuming that this flow is happening on the second page hit and not the first? Reason I ask is because it sounds like we make the server side call to Target as part of the request for the page markup with your recent response, which if that is the case would mean in your flow the assumption is the cookie is there already and because its part of the initial mark up request in the first page for the visitor request the cookie doesn't exists yet. That would mean you cant do any experience on the first hit of the visitor. Please let me know if this is correct.

[Arsène]

hello @josejr19  
can I pass the activity name in the data insertion api ?