Is it not sufficient to see if customers are using the feature? What are you trying to gain by learning if people turn off the feature?

@mmarques - we don’t use PX to do this, but we do have a method in our product for getting totals of things being used.   For example, how many people have deployed X template, or how many people have deployed style A versus Style B.   It makes it easier to see at-a-glance the popularity of certain features, versus having to do the math in analytics around how many people 1) clicked the toggle then cancelled, or 2) clicked the toggle on and then off again, or 3) how many people deployed and then deleted because they didn’t like it.    Some of this may be doable via funnels, but it seems like a lot of math or setup compared to just a simple “how many of X are deployed?”  or “how many have X enabled?”

Also, I think some of the “tracking” of this type of stuff assumes that if you’re using a toggle, the toggle’s CSS ID changes when it is “on” versus “off”.   To know if a feature remains enabled, you would need to somehow change the CSS ID of the element from “id=coolnewfeature” while the toggle is currently disabled, to then be “id=disablecoolnewfeature” when the toggle is enabled.   BAsically you could then track 2 different product mappings and then chart those to see how many folks enable vs. disable.

In our product, we’re not doing this.  A Toggle for a feature has a consistent ID whether it is enabled or disabled.   Basically, “id=coolnewfeature” (and a single product mapping) regardless of state, meaning PX would show 2 clicks for the same ID.  Do you then scope by account and just assume that if UserA clicks “id=coolnewfeature” but UserB clicks “id=coolnewfeature” they cancel each other?   Thinking through this makes my brain hurt.

@Ashton 
 

Thanks for reaching us on community.

You can rule out global context and custom attributes to achieve your use case.

Custom events can be the right solution.

According to you there are many toggles that can be on and off on your application, however you need to know which toggle is being turned on /off.

Implementation requirements:

One custom event with properties as per your need.

aptrinsic('track', 'Toggle Button', {
    "Feature Name": Feature One,
    "Feature Action": On
});

In the above example the Toggle Button is the custom event name and feature name & feature action which are referred as properties can be passed dynamically .

Also,

if you have a strong CSS pattern that changes upon on/off you can explore product mapper option too

Hope this helps, do reach us on pxsupport@gainsight.com for any addition questions our team can assist you!

Thanks

Dileep Nalla

Great post @Ashton !

Clearly, there are many options and I am not willing to say which is the best for every customer. ;)

I do think @rterakedis is spot on if you need to track the “ON” versus “OFF” click as separate Features, which does have great merit IMO.  

@mmarques is spot on too, once the product feature is enabled simply filtering for users that have accessed/used those newly visible pages/features in your application is a great indication of who has turned in “ON”. One potential challenge here could be knowing which users have turned the feature “ON” and just have not ever used any of those features.

And, @dileepnalla has offered a good solution using PX Custom Events for tracking purposes too. Implementing this will require a developer on your side to implement that code, so it may be “simpler” to just ask your developer to add a unique selector “id” or “attribute” to that HTML element so it can be easily mapped to a Feature in your Product Map … less custom coding required.

Personally, I would not rule our Global Context or Custom Attributes either, since they can have great value too.

Global Context is a perfect way to record application settings/variables that can change over time for a user (session to session, page to page, and/or screen to screen) and/or are completely different for other users. Good examples of these could be application version, build numbers, feature flags, etc., so having certain features enabled could be tracked with these properties and analyzed through many PX Analytics.   This option will require your application developer to add custom code to your application to set these Global Context properties on every page, so this probably requires the most custom coding.

Custom Attributes are a great solution if you are collecting more durable, longer term information like "persona" or "role" or any other specific user profiling data.  PX User custom attributes can be easily used as filters in all PX Analytics as well as in Engagement Audience logic.  And, since PX User custom attributes reside on the PX User's primary record, they are clearly visible inside tabular lists in PX such as Audience Explorer and Query Builder as well as directly visible on the main PX User Profile page.  This option will also require your application developer to add custom code to your application to set these Custom Attributes for the User/Account.

It is nice to have options!!! 

@Ashton  this is a common question for my team. We have GPX installed on 10 different applications, many tracking different attributes and events, and some tracking the same.

@link_black provided you with really great detailed options. Global Context, Custom Attributes, and Custom Events all have their merit. 

Here is how we make that call:

1. Is the data point most related to the user/account (attribute), the platform (context), or a moment it time (event)? This helps us determine where that data point should sit.
2. Is it something you want to track in aggregate, use in other filters, reports, or better yet measure across platforms? (If you answer yes to all of these, then as @link_black mentioned, a custom attribute is most durable. And if you need to consider the timeframe when this attribute was “on” make sure to add historical tracking to your custom attributes.)

In most cases, we find product toggles represent a moment in time when a user activated or deactivated something. The product feature easily tracks the interaction, but not the setting the user landed on. The Custom Event feature in GPX has come a LONG way in just the last year and you can use the event itself, its properties, and timeline in many filters, reports, or audience rules. And we have found that adding a custom event has one of the lowest task times of all of these options. (pretty close to the attribute task time, but far more bang for the buck.)

Hello,

here are my two cents as this is a topic that I repeatedly discuss with PMs. 

Our customers click on things (button, toggles, tabs, whitespace), there isn’t always value in a click. There could be value in understanding that the Toggle was in a true/false position when the user did 100 other things. So my line of questioning using follows this pattern:

1. Historical usage: Is the state of the toggle important to report against the other actions / events / engagements?
2. Realtime usage: Is the state of the toggle something you might want to use to manage your audience rules? Do you need to interact with the status of the toggle value in real time? 
3. Both?
4. Neither?

In many cases, we have added the toggle status as a user customAttribute, an account customAttribute or globalContext depending on how we answered the questions above. 

Historical reference: globalContext when we don’t need to know the value in real-time to refine our audience rules to trigger engagements or other immediate gainsight interactions (kb, etc).

Realtime usage: user.customAttributes or account.customAttributes depending on how who owns the ability to change the toggle (if the Admin is setting a toggle which impacts all users, then we set the value on the account. If a user sets a value which only impacts them, we set it on the user.

Both: we almost always include the attribute in globalContext so we can see how those values change over time.

Neither: then we don’t need it (said no one ever)….

xxxindicatoradminenabled: false
xxxngadminenabled: false
xadminenabled: false
xadminenabled: true
xxxxadminenabled: true
xadminenabled: true
xrequestsadminenabled: true
xrkadminenabled: true
Sxadminenabled: true
Sxaccountisallowedoptin: false
Sxuctorallowoptin: false
Trxadminenabled: true