Westpac App uses Target to send notifications. Notification Campaign should be shown only once per device. However, same notification is shown multiple times. Let’s talk about the symptoms and ways to fix it.
Frequency capping is an Audience manager capability. When you setup campaign segments you set the limit how many time you want to show some campaigns before bothering customers. We have some hard rules set by the legal team around how many is too many. In our case the limit is set to three and one for notification. More than that it goes around spam act.
How to debug the issue?
Two ways to debug the frequency issues. Using audience manager console tools > Visitor Profile Viewer. By entering the customer tracking id/mid you will see all the segments and its frequency. But this is not a very useful tool as this is not real-time delays make this tools for debugging useless.
Most useful way to debug is in target debug mode where it will show all the segment qualification but it will not display the frequency. But you can reload the page multiple time and see if the frequency capping is triggering on exact number of refresh and you are remove from that segment.
Why frequency count is an issue?
We have to understand some of the fundamental and product limitations. Let’s talk about the fundamentals first. In our implementation analytics data use in analytics to create audience treats and we use the analytics treats to create segments and add frequency count to the segments.
Target prospective
In the past Target server team have seen too frequent requests to AAM (especially when the account setting is using “real-time” to retrieve AAM segments) will cause performance degradation. To avoid this issue caused by poor implementation, Target server will ‘cap’ the calls to retrieve AAM segments after a threashold value has reached, and this will be reset after a while.
Solution
In mobile app implementation, we need to be able to tell the difference between various screens in the mobile app. Use this input parameter to provide a logical grouping of mboxes on the mobile app screen – one unique impressionId per mobile app screen. This is required to balance between fast mbox calls and getting the most recent AAM segments.
"requestLocation": {
"impressionId": "1553229996434",
},In our implementation :
- We use random number for impressionId
- For multiple mBox on the same screen, impressionId remains unchanged (for grouping purpose)
- Target v2 API allow batch call and used for multiple mBox calls
- Ensured all applicable use cases are thoroughly QA
SDK bug:
- From SDK v4.14 target introduce batch API(v2) and it regressed earlier impressionId implementation
- Adobe provided fix for this as part of iOS SDK v4.18.7 and Android SDK v4.17.9 version
Leave a Comment