Consent Monitoring: How to Audit Cookies & CMP

Hello. In this video, we'll explore how consent and cookie monitoring work in Trackingplan. Let's start by going into Trackingplan and heading straight to reports. If we click on advanced reports, one of the reports we'll find is consent percentages, which will show us the percentage of consent compliance. Once we open it, Trackingplan will automatically load data from yesterday, and we can choose between different data sources. Cookie management can be handled in two ways. by sending or setting data in the data layer so that Google Tag Manager uses this information to decide whether or not to fire each pixel or by implementing it directly through the CMP. So each pixel or analytics tool communicates consent directly with it. In this case, I'll select the CMP and analyze consent compliance for each of my destinations. What this report will do is show the percentage of user sessions executed without the proper permissions. In other words, how often data is being sent even when cookie consent has been denied. Meaning that anything above 0% indicates a potential issue worth reviewing. Let's run it. And the first thing we'll see is the overall section which shows the percentage of permissions not granted throughout the entire user journey. Based on one trust configuration, the tags are categorized as follows. C00001 for essential technical cookies. Two for analytics cookies. four for marketing and advertising cookies. And on this website, we also see UTIQ, which is another marketing tool. For example, we can see how Bing, which is a marketing tool, should operate under the CO4 category, but 0.5% of events still occur even though consent wasn't given. Similarly, for Critio, which has very little traffic in this case, we see that it is always firing without consent. Then we have the Google Analytics tags which fall under Caesar 02, but we'll look at those in more detail later. And in the case of meta, we can see that the marketing category is also firing in 0.5% of events despite consent was not given. Let's investigate what's happening by going directly to the data explorer. This will open a new tab in the data explorer with a filtered view displaying all meta events grouped by one trust Caesar04. Here we can see that 0.4% of the time data is still being sent even though the user hasn't accepted marketing cookies. If we want to add more filters, we have all these consent related properties available. First, I'll check the data layer to see if it's configured to store add consent. So, we can compare it with the C004 category currently shown in the view. And I'll also add the event name to identify if any specific event is causing the issue. Let's click explore. And here we can see that for the page view event, sometimes it fires when consent is granted as it should, but other times it fires even when consent is not given. In this case, because the data layer shows it as granted. And there's even a page view that still fires when neither one trust nor the data layer shows permission. So if we wanted to dig deeper into what's happening here, we could filter by the page view event when one trust C04 is either not granted or missing. And we could also add the page to see exactly on which pages this occurs and see cases where users didn't accept marketing cookies, but the page view event was still triggered along with a complete list of affected URLs. Now, if we go back to advanced reports on the tab we were on before and analyze the Google destinations, we'll notice something different. Some Google Analytics properties are still firing even though about 46.5% of users didn't accept Analytics cookies. That's because of Google's consent mode, which when configured in advanced mode, allows the collection of anonymized user data. But to make it work correctly, I need to accurately tell Google whether my users have accepted analytics or not. So to check that this is working properly, let's go back to tracking plans data explorer. This will load a view filtered by one trust consent data for the acceptance of CZ02 analytics cookies. But we can continue refining the filters under the consent section to see what data is available at the data layer level. Here I'm also going to select GCS GCD analytics storage which captures the consent data that's sent to Google. By clicking explore what we'll see here which applies to Google Analytics, Google ads and flood light is that when one trust consent is granted the pixel fires as expected and indicates that permissions are granted. And for example, when the user didn't accept cookies, we still sent a signal to Google but indicated denied. In those cases, instead of a full event, what's sent is a ping, a lightweight signal with less information. These pings help Google improve its data modeling without profiling the user. This is the main difference between advanced Google consent mode and the standard simpler version of Google consent mode. For example, here we can see that the user has accepted cookies and the data layer has recorded this correctly. However, pings are being sent to Google Analytics instead of full hits. This means we're mistakenly sending Google a denied signal, sending inaccurate data and creating minor inconsistencies that reduce overall precision. This is a situation worth investigating further where we could either drill down by adding filters or review individual user sessions that experience this issue. For instance, if we go to see tracks, we'll be able to view individual user sessions. This will take us to tracking plans tracks explorer, which shows complete sessions of real users experiencing the same scenario. Let's take this session as an example to see how its cookies behave. In the consent section, we can track when the user accepts one trust and what analytics data Google records throughout the session. By looking at the timestamps, we see the first page view occurred before the user had accepted cookies. Later, the user accepted cookies and continued browsing. However, there is an event called accept all cookies where even though one trust marks it as consented, the information being sent to Google is recorded as denied. The same applies to the click data track event. It also appears as denied. As we see, this issue doesn't repeat during the rest of the session. So in this case, we'd need to review this particular user session to understand the problem. Finally, one more thing to note. Besides exploring by destination, we can also review other options here. We can explore by cookies, by events, or in the group by section. We can also add more dimensions such as country. This visualization highlights different levels of consent and configuration adjustments across countries. Any country specific configurations would be visible here. And we could drill into the tracks explorer in the same way to investigate further. We hope you find this video helpful. Thanks for watching and happy tracking.