Web SDK QA with processing rules

[meghanpowers]

Hello!  We are in the process of implementing the new EDGE network Adobe Web SDK and redoing our tagging.  We've built some of the new server side tags with processing rules.  Question for the forum:  how can we QA events built in processing rules to make sure they are firing properly on the site?  With client-side tagging, we would look at events using dev tools and/or Adobe Experience Cloud debugger, but now we cannot see them there anymore.
Open to suggestions!

[RaawiMahendru]

Hey @meghanpowers 

Debugging is disabled by default, but can be toggled on in four different ways:

• configure command
• setDebug command
• query string parameter
• Toggling on Enable Debugging in Adobe Experience Platform Debugger. Adobe Experience Platform is a powerful tool that examines your webpages and helps you debug implementation issues with your Experience Cloud products. Adobe Experience Platform Debugger is available as both a Chrome and Firefox extension. Debugging can be enabled from the configuration tab of the AEP Web SDK section.

Please refer to : https://experienceleague.adobe.com/docs/experience-platform/edge/fundamentals/debugging.html?lang=en for more details.

[meghanpowers]

Thank you for the reply!  We know how to turn on the debugger.  My question is how do we see events (custom events in Adobe like event 5 = lead submit) IN the debugger (or dev tools) when they are built using a processing rule?

[RaawiMahendru]

Hey @meghanpowers  - Thanks for the clarification, Have you tried enabling the Retrieve Post-Processed Hits option ? You should enable that if you want to see the values on Analytics hits after processing rules have run. You must be signed in to Adobe Experience Cloud for this feature to function.

When this option is enabled, a debugging parameter is added to your Analytics requests. Hits continue to be processed like any other hits. Platform Debugger polls the Analytics debugging API to retrieve post-processing rules values for any hits that have an original Hit ID. Post-processed hits have a purple background and are shown next to the original hit.

[meghanpowers]

That's really interesting - thank you for the suggestion!  Do you know where I go (in Adobe admin?) to enable that?
And do you know if it counts against our server calls or anything?

[yuhuisg]

This feature was available in the old -- and now-deprecated -- Adobe debugger. The current Adobe Experience Platform Debugger does not have this feature, which is a huge loss precisely for this ability to inspect post-processed data.

Having said that, I don't know if the old debugger can show the post-processed data for data collected via Web SDK. I haven't tried it myself, but would be keen to know.

[yuhuisg · Accepted solution]

Processing Rules are an Adobe Analytics feature and have no relationship with Web SDK.

Think of Web SDK as a replacement for Analytics' own AppMeasurement, the code that collects Analytics-specific data to send to Analytics. But because Web SDK is not the native method for sending data to Analytics, so the Adobe debugger is not able to show the processed data after Processing Rules have been applied. You will have to rely on the final reports in Analytics to debug your data collection.

[meghanpowers]

thank you!

[namandeepkaur]

Hi @yuhuisg  How can we make sure in the analytics debugger tool and the network tab, there are no duplicate webSDK hits after the event gets triggered?
Currently, I'm pushing a sample datalayer object but I see multiple hits in the network tab and debugger tool from the same event.

[yuhuisg]

If you're seeing multiple hits for 1 expected hit, then that could be an implementation error, e.g. you are sending the same hit more than once, or if you're using AEP Tags, then you may have more than one Rule that is sending a Web SDK event.

If you're seeing always seeing 2 hits where you expect 1, and you're signed into your AEP Debugger browser extension, then the 2nd hit would actually be the response from AEP Edge server with its hit validation results, which are used in the Debugger extension's Logs > Edge view.

[namandeepkaur]

thanks @yuhuisg for the response! I see for 1 event, sometimes 6 or 8 hits both in the debugger logs and in the network tab. Any idea why this could be happening?

[yuhuisg]

I wonder if what you're experiencing is where 1 user action in the website is causing several "webInteraction" events (e.g. Custom Links in Adobe Analytics) to be sent together. 

Have you verified that all of the 6-8 hits have the exact same data in them?

[namandeepkaur]

Yes, 1 web-interaction is causing multiple hits in debugger. And I checked the hits, all of them have the same data in them. Any idea what could cause this issue?

[Pankaj_Sabharwal]

Hello @meghanpowers 

Here’s an in-depth blog about the same. Hope this helps.

https://experienceleague.adobe.com/docs/platform-learn/implement-web-sdk/applications-setup/setup-an...

Thanks

[Vijayakumar_Raju_CBE]

Hello All,

if we are going towards the processing rule "Use Adobe Analytics processing rules to set custom variables" mentioned in this URL https://experienceleague.adobe.com/docs/platform-learn/implement-web-sdk/applications-setup/setup-an...

To map the custom variables for Web SDK approach, then I have one question. Looks like for each report suite we have maximum of 150 rule we can create in processing rule then how come we accommodate all the custom variables (props 75, evars 250, 1000 events) in a single report suite????

Thanks,

Vijay

[yuhuisg]

You can try asking Client Care for an increase in the number of Processing Rules. You may have to pay for additional rules.

[Vijayakumar_Raju_CBE]

Thanks @yuhuisg this make sense its kind of additional cost that needs to be pay if we are going for the processing rule approach especially with the AEP SDK.

Regards,

Vijay

[acookie4rachel]

It’s been some time. In case anyone stumbled upon this thread and still looking for a way to debug your AEP Web SDK AA implementation real time (including Edge trace for XDM), you can now use the Assurance tool that works out of the box from AEP or connect the Edge debug session via the Experience cloud debugger to launch Assurance.