This section will discuss where tags should not be placed and the limitations of tagging certain properties to gain Resonate insights.
Properties that should not be tagged
Although tagging your digital properties to collect data about your audiences is encouraged, we would like to note that there are a few properties you should not tag:
- Mobile Apps - Our Site Tag is not optimized for mobile applications, so we cannot get enough samples from Mobile Apps to predict insights.
- Social Pages - Social media platforms typically do not allow third party tags to be placed directly on their profile pages (e.g., Facebook pages).
- Email - Third party tags are often blocked or do not work as intended in common Email Service Platforms.
- Analytic Tags, marketing trackers, and third-party cookies set in emails and in mobile app web views rarely produce modeled devices, which then in turn produce no insights in Resonate Ignite.
There are also additional properties where tagging is not recommended since cookies on these digital assets are not persistent and/or stable enough for insights:
Sites that draw mostly mobile-only traffic:
- A large contributor to this problem, and an industry-wide challenge, is that Apple iOS and the Safari browser do not permit third party cookies to be set.
- This is an industry level problem and not a Resonate specific challenge. This industry-wide lack of analytics beacon persistence means that a greater amount of traffic can be required to achieve enough behavioral data capture to generate robust models for insights.
Email Tagging Limitations:
- Insights on a Tag are available once there is an adequate amount of statistically significant data to build an audience profile. In order to achieve this, Resonate needs sufficient matched modeled devices - where the device has viewed the Tag and also exists in Resonates modeling infrastructure.
- Match rates on Tags in an email can be far lower than Tags on websites. Email desktop clients and webmail clients, such as Outlook, tend to allow a Tag to be set but do not allow the Tag to persist. Meaning the email client can delete the ID from the Tag. The Tag is often set and counted but it is removed automatically when the user’s session ends, which delays us from capturing enough online behavior to generate robust models.
- The above factors may create a situation where more uniques than you are used to seeing with website tagging are required to achieve statistically significant sample for insights on an email Tag. It could be as high as 4 times more.
Mobile tagging limitations:
- Match rates on Tags on web views in mobile applications can be can even lower than email tags. Web views that occur in mobile apps also tend to allow a Tag to be set, but do not allow the Tag to persist. Therefore, the ID from the Tag is also getting deleted. Once again, this creates a situation where more uniques than you are used to seeing with website tagging are required to achieve a statistically significant sample for insights on a mobile Tag. It is usually about 10 times more.
- Another consideration is if a user is linking out to a landing page from a Mobile app, and it opens that user's browser. If that browser is Safari on iPhone, the tag is not going to be recognized. The same is true for any channel that has a significant amount of mobile traffic, for example Facebook, Instagram, and other social media apps.