How to see in debug tool which rule in adobe launch pushes data to adobe analytics? | Community
Skip to main content
A
aagk123
Level 5
November 3, 2022
Solved

How to see in debug tool which rule in adobe launch pushes data to adobe analytics?

  • November 3, 2022
  • 3 replies
  • 6537 views

For example in my launch account I can see multiple page view rule set up but with omnibug I cant say which rule is pushing data on page load. Is there a way to find which rule send data on page load or event using chrome debugger tool? Also if you have some source link on how to use google browser debugger tool effectively that would be great.

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by yuhuisg

Try this:

Create a Rule Name data element from the Core extension's Runtime Environment section.

In your Analytics extension's Custom Code, add this inside the s_doPlugins() portion:

console.log('Send Analytics beacon: ' + _satellite.getVar('Rule name', event));

That should result in your browser logging the Rule name that sends any Analytics beacon (page view, custom link, etc).

3 replies

Jennifer_Dungan
Community Advisor and Adobe Champion
Jennifer_DunganCommunity Advisor and Adobe Champion
Community Advisor and Adobe Champion
November 3, 2022

So I use a combination of tools...

 

First and foremost, I use the older Adobe Debugger Tool - "Adobe Experience Cloud Debugger" (https://chrome.google.com/webstore/detail/launch-and-dtm-switch/nlgdemkdapolikbjimjajpmonpbpmipk) - I really hate the new tool, and the way it works, showing only one tab at a time makes it completely useless for my needs. That and showing me mostly irrelevant data near the top and needing to excessively scroll to see the important stuff just makes it not worth using. The old tool however will show me ALL the different suites for all tabs, so I can compare prod to qa running in different tabs, and with less bloat, it's better for me.... but some people like some of the features for the newer tool, and if it works for you I support your choice (newer tool: "Adobe Experience Platform Debugger" - https://chrome.google.com/webstore/detail/adobe-experience-platform/bfnnokhpnncpkdmbokanobigaccjkpob) 

 

 

Then I also use "Launch and DTM Switch" (https://chrome.google.com/webstore/detail/launch-and-dtm-switch/nlgdemkdapolikbjimjajpmonpbpmipk) (I don't use the environment switching capabilities, I find those buggy), but I do use the "debug" feature which writes logs into the Chrome console which tells me which rules are triggered (or which rules don't meet the conditions to trigger - if you are using conditions to control your rules), in which order, and with some context I can see what is happening and which rule(s) are sending data or triggering on each page or action. I think this tool may solve your ask about "is there a way to find which rule send data on page load or event"

 

 

Sometimes I will test using the Network panel directly. I will filter for "b/ss" and look at the parameters. Once you get the hang of reading the designations ("g" is the url, "ch" is the channel/site section, "c#" are your custom props, "v#" are your eVars, "h#" are your hierarchies, etc) it becomes easier to read; and if like my, some of your calls are so long they become sent via POST; you can copy the Request Payload, and use something like Excel or a Google Sheet to use the "Text to Column" function, delimiting on "&"; or use a text editor to replace "&" with line breaks (you need a text editor that supports replace with \n or \r for line breaks); this will make the data readable for testing.

 

 

 

I assume by "chrome debugger tool" you are referencing "Adobe Experience Platform Debugger"? As you can see from above, I really don't have a lot of tips to use that tool effectively, since I don't find it terribly effective 😛

But also, in order to help you, knowing your testing style (Do you stick to a single tab? Do you use multiple tabs? Multiple Windows? Are you doing ad hoc testing, or are you doing a systematic check item by item again a requirements document?) would help us to try and help you.... everyone has a different style, and I would want to try and take your needs into consideration for any recommendations that I might give you.

 

I will say this, if you are doing systematic checks again a requirements document, making sure the items in the document are in the same order as the tool will show things goes a long way to efficient testing (no matter what your testing method) - as this will prevent a lot of scrolling back and forth in the doc / tool to try and make sure everything is there and correct... and reduces the chance of missing something.

 

Hopefully this gives you a place to start, let me know if you have any more questions, or have any specific asks about the tools.

    R
    rudraWiley
    Level 3
    June 7, 2023

    Is it possible to see same in web SDK? some how _satellite.setDebug(true) is not working.

    and gives below 

     

    yuhuisg
    Community Advisor
    yuhuisgCommunity Advisor
    Community Advisor
    June 7, 2023

    That is the correct logging for Web SDK. Its codename is "alloy", so those lines that start with "[alloy]" are coming from Web SDK's debugging.

    yuhuisg
    Community Advisor
    yuhuisgCommunity AdvisorAccepted solution
    Community Advisor
    November 3, 2022

    Try this:

    Create a Rule Name data element from the Core extension's Runtime Environment section.

    In your Analytics extension's Custom Code, add this inside the s_doPlugins() portion:

    console.log('Send Analytics beacon: ' + _satellite.getVar('Rule name', event));

    That should result in your browser logging the Rule name that sends any Analytics beacon (page view, custom link, etc).

      J
      jlinhardt_blueAcorn
      Level 3
      November 3, 2022

      Hi there.  

       

      We actually capture the name of the Adobe Launch rule in a prop, so we can run troubleshooting reports in AA to identify the exact rule that we need to fix (when an issue arises).  This would also mean the prop would show up in any of the debugging solutions that are available.

       

      If that doesn't work or if that isn't of interest, have you tried using a developer tool's console and using the "_satellite.setDebug(true)" command in the console?  Once  you type this command into the console, simply refresh the page and you'll see everything that adobe launch is doing in your console, including the names of the rules that are being fired.

      Terms & ConditionsAccessibility statement

      Loading footer...