Using _Debug

Our Javascript SDK comes with some tools to help identify potential issues built in. The first of these is the _debug argument for the $p("track") function.

Function arguments:

$p('track', {
      elements: document.querySelectorAll('#li-recommendation-unit > div.recommended_item'), 
      name: 'my-widget-name',
      source: 'LI',

     _debug: true

}

• elements: An array of the DOM elements that should be tracked. The selector should be the entire DOM element corresponding to a particular recommendation. In the example above, the Mustache.js template uses #li-recommendation-unit for the widget area and 'div.recommended_item’ to identify each item within the area.
• name: Name of the widget being tracked (this should match the name set in the $p("register") "widget" argument).
• source: Name of algorithm active during this impression. Please use ‘LI’ for LiftIgniter. In an A|B test, you can use a variable name here and define which algorithm ('base' or 'LI') is being used to generate the recommendations.
• _debug: Optional, for help with testing. When set to "true", browser alerts will appear for visible and click events on elements being tracked. Make sure to remove or set to "false" before pushing your code to production!

If _debug is set to true, you should see the following in your browser:

• When the items being rendered first enter the viewport, you should see an alert pop up saying something like "visible for default-widget:LI". This means that an event was triggered telling the LiftIgniter system that the items entered the viewport.
• If you click on any of the recommended items, you should see an alert pop up saying something like "click for default-widget:LI". This means that an event was triggered telling LiftIgniter that the user clicked on the recommendation. To make debugging easier, we recommend right-clicking so that you do not accidentally navigate away from the page.
• You can see the exact events that are being sent to LiftIgniter by going to your Network Panel in Chrome Developer Tools and filtering to petametrics.com. This will include both the widget-specific events and pageview and heartbeat events. For more background, see the Widget Events page, which builds on some other pages in the web debugging section.

Using $p("runDiagnostics")

Our second tool, which offers a more thorough analysis of Javascript performance and can inform you of potential issues with activity tracking, inventory collection, and more - you can find more details on using this in our $p("runDiagnostics") article.

Verifying Tracking Accuracy

Using the _debug argument in development environments will help ensure events are triggering successfully. However, we also need to check that the right values are being sent for each event. Below is a checklist for each of the widget events you'll be seeing in the Dev Tools Network log.

Widget_shown and widget_visible

1. Only one widget_shown and at least one widget_visible event is fired for each widget on the page
2. The visibleItems (vi) parameter in each widget_shown and widget_visible event contains the correct URLs for all of the items displayed
3. Check the list of visible items is the same as the list returned by LiftIgniter in the "widget_response", and are displayed in the same rank order (the highest ranked item should be in the first/most visible space in the widget area)
4. If only a few of the items are visible at a time (such as in a carousel or paginated display) make sure that widget_visible contains only the items actually visible to the user. Additional widget_visible events can be triggered as the user scrolls through additional items. Please contact Support if you have any trouble with this!
5. If you see the widget_visible and widget_click events, but do not see our tags (&li_source=LI&li_medium=<widget-name>) in the URL after you clicked to it, this may be because your site automatically rewrites or strips off tags. This is not a problem for our tracking or for training our algorithms, but it will make third-party verification of the numbers harder and means that some of the analytics we compute won’t be available (such as calculating the rate of a second widget click in a session).

Widget_click

1. Make sure only one widget_click event is sent when an item is clicked. Multiple click events usually mean the "track" function has been applied multiple times to the same DOM element. This can happen in single-page web applications or other setups where page content is updated or replaced dynamically.
2. Make sure the "cu" and "ccu" value for the click event is the URL of the page where the widget is displayed. "cu" is the current URL - this may have query strings included, and should exactly match the URL displayed in the browser window. The "ccu" is the current canonical URL and should have only the base URL with no query strings included.
3. The "clickUrl" value should be the URL of the item that was clicked on.
4. If you are using any on-click overrides, this can cause our click tracking to fail! Make sure that every link goes to the intended recommendation rather than the baseline recommendations or looping back to the current page.

Understanding the Data Being Sent

Widget shown and visible events contain the following fields  as part of the data sent in query.petametrics.com/__activity.gif :

• vi (stands for visibleItems): This is the list of all the visible items in the recommendation section. This includes all items that match the selector inside the widget area. All widget events associated with a given rendered widget should have the same value of vi. Note that the set of visible items should ideally match with the inventory items being recommended, but it is possible to have additional visible items (such as links to author or section pages that render within the widget). If you have a situation where the anchor link differs from the inventory item being recommended, please get in touch with Support.
• w (stands for widgetName): This is the name of the widget being rendered. It should match the same you use in your register and track calls.
• source: This describes the A/B test slice. If LiftIgniter's recommendations are used, this should be set to "LI", otherwise it should be set to "base". This value should match the value you set in your track call.

In addition to the fields listed above, the widget_click event has the following fields as well:

• clickUrl for the URL that was clicked
• trigger describes the trigger for the click. It can take two values: click (for a left click) and contextmenu (for a right click).