Skip to main content

Our team is currently exploring ways to track data visible within our UI using Gainsight PX, with the goal of leveraging that data as audience parameters for targeted engagements.

However, due to roadmap priorities and limited engineering resources, our stakeholders are hoping to avoid the need to modify the identify call or implement custom APIs to pass this data.

A common use case we’re trying to support involves users encountering various billing-related errors—for example, “denied #”, “rejected #”, etc. While we understand that unique data elements or HTML classes can be used to trigger engagements, we’re running into challenges when those sections of the code are not uniquely identifiable or the text (denied, rejected, etc) related to the number (10, 20, 30) is in a separate class, unrelated to each other. 

So here’s our question:

  • Are we stuck when the UI elements lack unique identifiers in the HTML?
  • Has anyone found creative or scalable solutions to this problem?

We’d love to hear from others who’ve tackled similar scenarios or have ideas for how to work around this limitation without a heavy engineering lift.

Thanks in advance! 

Hi Tyler. It sounds like you have a pretty good handle on the available options. The 2 I’d highlight as ideal would be:

  1. Find something in the url (path, hash or query params) that reflects the specific error or error code, OR something in the CSS hierarchy that does the same. Remember custom CSS attributes like data selectors can be added in SDK settings. That attribute can be used to map a feature in product mapper, and the feature used in your engagement logic.
  2. If #1 isn’t possible, that’s where custom events come in. Pass an event like aptrinsic(‘track’, ‘error’, {code:var, message:var, etc.}). This can get used in product mapper if you want to track it, or just directly in audience logic to trigger engagements in real time.

There are other options, but they all require more engineering time and/or compromise real time engagement qualification. Of the 2, the custom event is the most adaptable and evergreen, assuming the error event is applied at a high level to catch all errors shared in the UI.

I know the limitation is a drag, but the upside is end-user data security.

Reply


Terms & ConditionsCookie settings