Expand my Community achievements bar.

SOLVED

Is it possible to set context data in interact calls (Web SDK) and use processing rules ?

Avatar

Level 2

We have a usecase where we are adding certain query parameters to our current t and tl call via akamai, and which is further set to eVar or prop variables using process rules.

We are exploring migration to WEB SDK, so we wanted to check if we still continue to add query params on the interact call, we could use processing rules for it ?

 

Also i read some where processing rules does not work for calls made via WEB SDK, not sure if this is true or not.

Any help is appreciated ! 

Topics

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

1 Accepted Solution

Avatar

Correct answer by
Community Advisor

Hey @Morish2412 

Till the time you are able to send through the query parameters as part of any key in the xdm schema being used in the datastream, you can then use processing rules in the analytics interface the way you've been doing with app measurement.

 

There are currently two ways of capturing data using web sdk for analytics.

 

1. You map the values to the individual eVars and props in the _experience field group. In this scenario, you don't need processing rules and the data maps directly to analytics evars and props.

 

2. Use your own custom field group and key value pairs to first capture the values using the web sdk and then, use processing rules in analytics interface to map it to respective eVars and props.

 

There is a nice series of blogs written by @PratheepArunRaj around the entire migration piece.

 

Hope the above helps.

 

Cheers,

Abhinav

View solution in original post

4 Replies

Avatar

Level 4

Hello @Morish2412 , 

 

With the Adobe SDK extension in Launch, you can define a lot of rules that you previously would define in processing rules.  Example is email query.  Now, you simply define the child data-element, and then fold it up into a parent XDM data-element for what you are trying to solve for (in the example image that is pageview).  

 

After you have established all of the related rules and data-elements you ensure your schema is set up to pipe data to Adobe Analytics, Target, Marketo, etc.  

Avatar

Level 2

I guess i was not clear enaugh.

Currently we are appending some extra query parameters to our t and tl calls. like in the screenshot below, and we use processing rules to capture it.

Morish2412_0-1711752700610.png

 

Similar to this, is it possible to do the same for the interact calls that are triggered using websdk.

Something like this, in the below screeshot you can see the interact call, with some additional query param.

Morish2412_1-1711752787678.png

My question is that can we capture from the interact query paramerter using processing rules or not ?


Currently we dont use Launch for implementation

Avatar

Community Advisor

Hi @Morish2412 , 

I have some good news for you. I was in the data streams lab at Summit, and XDM streams, if not doing it right now, will soon support custom tagging, including a direct to Adobe Analytics syntax that will allow direct mapping to eVars, props, and yes, context variables, that will go through existing processing rules 

Avatar

Correct answer by
Community Advisor

Hey @Morish2412 

Till the time you are able to send through the query parameters as part of any key in the xdm schema being used in the datastream, you can then use processing rules in the analytics interface the way you've been doing with app measurement.

 

There are currently two ways of capturing data using web sdk for analytics.

 

1. You map the values to the individual eVars and props in the _experience field group. In this scenario, you don't need processing rules and the data maps directly to analytics evars and props.

 

2. Use your own custom field group and key value pairs to first capture the values using the web sdk and then, use processing rules in analytics interface to map it to respective eVars and props.

 

There is a nice series of blogs written by @PratheepArunRaj around the entire migration piece.

 

Hope the above helps.

 

Cheers,

Abhinav