Forum Discussion
Push Opt-Out Tracking - Workarounds 🤓?
Hello to all the creative workaround masterminds in here.
I've been thinking about push-out out tracking approaches and would love to see if you have any other ideas.
First, some context:
What: I'm looking to set up a Push Opted-Out event or some sort of directional tracking when users revoke the permission on (one of) their device(s). We can use this as a guardrail metric against our push campaigns.
Why: It's a nice guardrail, especially for scaling CRM teams/Lifecycle strategies. It helps sense checking what users might get value from vs feel annoyed with. It helps address stakeholder concerns around sending too much/too little in a data-driven way, rather than gut feeling. Even if it's a directional metric.
In our case we use Braze + Mixpanel, so the obvious solution to above is to use an "All events" Currents feed and stream the Token State Change event into Mixpanel (users.behaviors.pushnotification.TokenStateChange >> push_token_foreground_push_disabled=true ).
However, life is not always that easy and there's a chance I can't get approval on the extra budget to enable that (we have a more limited Currents setup at the moment). I've worked in companies with tricky setups where data activation is hard and Currents is not used, so I guess this might be relevant for other use cases as well...
To get ahead on alternative solutions, I thought of below -- but please share if you have other ideas?
- [No dev dependency] A scheduled Braze Canvas that periodically detects “now push-ineligible” (foreground push enabled for app changes to false) and logs a custom Push Opt-Out Detected event in the users' profile (via a webhook calling brazeBridge.logCustomEvent("completed survey").
- Pro: relatively easy setup; can be used as conversion event in campaigns/canvases.
- Con: probably very close to the TokenStateChange event provided by Braze, but won't be streamed to CDP/Mixpanel (for the same Currents feed limitation); usable only within Braze.
- [Dev dependency] Client-side instrumentation to detect permission changes and send a custom event from the apps.
- Pro: as accurate as Braze's TokenStateChange event, and will be available at every data tool we need (CDP/Mixpanel/Braze etc)
- Con: dev work (+dependency with product roadmap) + is it even worth the effort vs cost of upgrading Currents feed type?
Appreciate!
3 Replies
Of course, expanding your currents to mixpanel is the direct path.
What about an action triggered canvas when the user unsubscribes from push and then compose and send an unsub event via webhook to the cdp and mixpanel endpoints?Hi inespais​
One quick question on your Currents setup. Do you currently have any Message Engagement Events (for example users.messages.webhook.Send, users.messages.webhook.Abort, or Canvas experiment step events) or subscription group events configured to flow into Mixpanel?One additional option, if you have access to Query Builder (under Analytics) , is to bypass workarounds entirely and query push token state changes directly.
You can use the query below to identify cases where foreground push was explicitly disabled at the device level, and then reuse the same logic in Dashboard Builder for ongoing tracking:
SELECT TO_DATE(DATE_TRUNC('day', TO_TIMESTAMP_NTZ(TIME))) AS DATE, COUNT(*) AS COUNT FROM USERS_BEHAVIORS_PUSHNOTIFICATION_TOKENSTATECHANGE_SHARED WHERE TIME > (DATE_PART(EPOCH_SECOND, CURRENT_TIMESTAMP()) - 2592000) AND PUSH_TOKEN_FOREGROUND_PUSH_DISABLED = TRUE GROUP BY DATE ORDER BY DATE ASC;This will give you a daily count of users who have flipped foreground push to disabled over the last 30 days. (Tailor the query according to your needs)
If this table is available in your workspace, it’s generally the cleanest and most direct signal for push opt-outs. The Canvas / Message Engagement Events approach is mainly useful when this table isn’t accessible due to a more limited Currents or analytics setup.
