← Selected work · All case studies · How I work
Agreeing on what trustworthy data should look like
A small tracking request became a shared plan for dependable measurement: define the events, agree on variance, and give each kind of validation an owner.
My role: Led the Digital Optimization Team. This case focuses on shared tracking requirements and a validation plan with analytics and implementation partners.
The team: Digital Optimization Team (DOT), analytics, and implementation partners, with separate owners for implementation checks and data validation.
The full story
Make agreement testable
One integration discussion began with what sounded like a small configuration request: create a tracking variable. It became a much better conversation when the team brought up earlier discrepancies between the tools, questions about tag order, and gaps in the implementation documentation.
The group agreed to bring the people with the missing context back into the discussion and document the setup before moving ahead. The work was not tied to a release deadline, which gave the team room to understand it properly. That was a useful challenge to the scope of the ticket, with a shared aim: dependable measurement without avoidable rework.
Write requirements at the event level
The business requirements document specified experiment and variant tracking, action events, tag-order documentation, and avoidance of duplicated page views. Those details connected the business need for dependable results to behaviors that implementation partners could inspect.
Give each kind of quality assurance (QA) an owner
The document separated checks of the implementation from checks of the resulting data. It also called for performance checks, scalable server-call behavior, and alerts if the integration failed. This addressed both whether events moved through the system and whether the resulting data could support an experiment readout.
Design for the people who maintain it
The requirements included self-service management of experiment tracking variables by DOT developers. That made day-to-day maintainability part of the integration brief, alongside correctness at launch.
Status at my departure
The requirements were approved and awaiting development when I left Ulta Beauty. The integration had not launched. A larger initiative to migrate the testing platform from AB Tasty to Adobe Target was also underway; I cannot confirm whether this integration work was ultimately carried forward or superseded by that migration.
The requirements, in plain sight
The original integration brief made four expectations explicit:
Agree on variance. Target no more than 10% discrepancy between platforms. This was the agreed target.
Define the transfer. Capture experiment and variant data in Adobe Analytics variables through a custom integration using the Web SDK and Tealium.
Avoid duplicate counting. Aim to send test data in one hit or server call without duplicating page views and other key metrics.
Document the sequence. Make tag order and architecture visible; the brief preferred visual documentation.