Welcome back!
In our previous parts in this series we covered the security related aspects of tag management with Content Security Policies and Subresource Integrity validation, then we moved on to the more marketing focused discussion of cross-site tracking and attribution. Now, we close the loop on those topics with a discussion on suggested team structure.
Over the past few entries, I have tried to show that going forward tag management will require a diverse array of skills to be effective as intended. What should be clear by now is that unless your company has a mythical unicorn of an employee—we’re likely to need a cross functional team of some sort to achieve a workable solution.
Let’s start by crafting said mythical unicorn job description.
Seeking a tag implementation specialist who is
- Well versed in data collection practices for (platforms of choice)
- Proficient in web application security practices with regard to PII or Payment Card data.
- Knowledgeable about browser changes with regard to impact on tagging
- Able to speak to the effect of current and pending legislation in a global context and its impact to data collection and data storage.
- Able to troubleshoot complex systems related to the above.
That may be hard to come by—or at least—not cheap to come by. Really however, we’re looking at a few major focuses.
- Data collection should be legal and done securely.
- Data collection should be as accurate as possible with regard to legal/ethical/technical limits
- Someone keeping up with pending legal changes.
- Someone keeping up with pending technical changes.
So breaking this down further..
Core Team Members
Analyst: We need an analyst to craft a measurement strategy and run the analysis – keeping in mind external changes.
Developer: We need a developer who can implement what the analyst requests and do so in a secure fashion. Who also tracks technical changes and their impact on the system – and then communicates those impacts to the Analyst.
Optional (depending on use case/operating area) components:
Security Reviews: If we are running analytics on pages which contain PII or Payment Data.
Legal Reviews: To ensure any data we are collecting is legal in our respective markets and we’re abiding all laws we may be subject to.
Since getting cross functional teams aligned is difficult—I would recommend a single team, containing cross functional members, who have the same reporting structure allowing for an increased velocity.
Workflow
So now that we have a team in place (or can at least draw upon other folks for said roles). What should a workflow look like? Here’s my take on a suggested path.
For any new tag/vendor:
- Establish contract
- Security Review (if needed)
- Legal Review (if needed)
- Developer Review (to ensure it’ll work on the site as advertised).
- Data Retention requirements defined.
- Analyst provides measurement plan.
- Developer implements measurement plan.
- Configuration reviewed by Security (if needed).
- Deployment to production.
- Periodic review to account for external changes (Legal, Technical [browser changes])
This workflow ensures that you have data retention defined, that you have a binding agreement in regard to security and legal requirements which can be supplied to auditors, that you have a measurement plan, that the code will work on the site and is placed on the site securely and that a periodic review of the above is occuring to ensure that the system continues to work as intended.
Conclusion
The browser changes and laws are not stopping any time soon—if the various parts of the organization are not speaking to one another—there is an increased risk in data breaches, legal/industry non-compliance, and unforeseen impacts to analytics, tagging, attribution and by extension marketing spend and the bottom line.
Tag Management is changing and I do not believe siloed team structures are in a good position to succeed going forward, as there are simply too many moving parts that cross into non-primary domains to expect one team member / siloed group to keep pace on top of their normal duties.
It’s an ideal time to step back, figure out how data collection will work for your organization, and craft a cross functional team to ensure that tagging is done correctly from a legal and technical standpoint and find solid footing for running a data governance program (if you haven’t started already).
The year 2019 has been rough on tagging. It’s not over, and more changes will happen in 2020. Edge will launch in January, the CCPA goes into effect in January and Google is changing cookie handling in February for Chrome – that’s three sizable changes in the first two months of the year, and I have no expectation to think it’ll stop there.