Make Launch Better: Consent Mode

Launch (sorry, Data Collection Tags) has been in the wild for 6 years. Since then, the team has gone through a lot of changes. New product ownership, resources reallocated to other projects, and generally work reprioritized to other stuff like Event Forwarding. The great thing is that the team is working on some really cool, new stuff. The downside is that innovation has sputtered in the implementation space. Now the downside of all of this is that implementation complexity is maintaining a steady climb. I can’t tell the Adobe execs how to allocate their team resources, but since I spend a LOT of time in Launch I can hopefully get some conversations started and time/money allocated to incrementing this platform.

One of the biggest opportunities in Launch is how it handles consent (or how it honestly doesn’t). One of the biggest value propositions of Launch was that you can take a look at an implementation from the perspective of the action someone takes. That’s beneficial because an action someone takes can trigger many different tags. Let’s say your website has 20 different tag vendors and you’re tracking somewhere around 15 actions. Instead of starting from an interface where you’re sifting through over 200 different tags, you’re beginning by thinking top-down. What action are we tracking? Okay, now let’s see what tags correspond to this action.

Consent blows this whole thing up. Currently, you need to create a different rule for each consent status. This completely undermines the architecture of Launch. Instead of thinking top-down, we’re now having to start with thinking about cookie functionality and work our way backwards to the user. So if I want to update a tag that triggers on a receipt page, instead of looking for the Receipt Load rule I’m trying to decide between 3 or 4 different rules all corresponding with the receipt loading because each of them requires a different Event or Condition. This is dumb, it wastes time, and everyone does it a different way.

How I’d Do It

I’m not graphic designer or a developer. However, I have some conversation-starters. Let’s start with what we want:

1. I don’t want to have to create a different rule for each level of consent.
2. I want an easy way to see all of the tags that trigger under a single user action.
3. I want an Adobe-native and supported way to manage consent.
4. I want a standardized methodology of implementing consent.

Tall order, huh? It might not be as bad as it looks… at least for the VAST majority of users. Let’s start with the UX and then we can talk about how this would technically integrate with the Launch architecture. First of all, we have to define the different types of consent. OneTrust’s consent cookie looks something like this:

Awesome. Now we need to slot this into the different consent buckets.

 

You can do your silly string matches here with Regex. Hooray! In this example, I only put 4 cookie categories because this takes care of 99% of cases. If we want to make everything way more complicated, we can add a dynamic category – but we’re not designing for the super special folks who need that. Now that we’ve defined the cookie and classified the user, we need a way to apply it to tags in a rule.

Booyah. Since we’re moving back to a structure that makes sense… you know, with many tags in 1 rule… let’s make sure consent is easy to scan/process when rules are opened.

Hey look, the colors mean something now! That’s it. That’s how consent should work. Now I’m sure there’s some big important reason I’m missing here. Let me try to cover a few:

Hey, some people don’t even use a consent manager!

Then make this toggleable in the property settings.

Sometimes I trigger a tag in the condition!

You’re clearly already doing things the hard way – this does not impact your wacky implementation.

What about existing extensions that create actions? Would this break them?

Not if it’s coded by a sane person. They would all inherit this functionality and default to either no status or Essential until it’s configured otherwise.

Why not build this as an extension?

Impossible. That’s not how extensions work. This would have to be built by the Launch team.

Final Thoughts

For those skipping to the end – THIS IS A FEATURE REQUEST. This is NOT a current existing feature in Launch. The problem we’re trying to solve here is the 100 different ways there are of solving for consent management in Launch without undermining its benefits. Currently, consent management makes everything harder. It doesn’t have to be like that. I would love for the Launch team to take this and run with it. There are likely architectural barriers to implementing this, but it’s worth solving.

Like I said in the opening paragraph: stuff is getting more complex and we rely on vendors to help mitigate the complexity they’re creating. I hope we’ll see more investment in the client-side version of Launch, but until then we may have to suffer through 200 more articles articulating different ways of completing the same exact task.