One easy way to avoid this kind of mistake in your own product: make a clear distinction between your publicly-facing web site ("corpweb") and your web app for logged-in users. Preferably, they should be served from separate infrastructure.
Corpweb should be as static as possible, except for whatever third-party JS the marketing professionals think is necessary. It's their job, they know what's best.
Your app should have zero third-party JS except for technical analytics (New Relic, Datadog, whatever).
(This distinction can be fuzzier for free services, and for consumer stuff with non-sensitive data; Backblaze is neither of those.)
That made me LOL. You'd like to think they know best. Most of the time, they do things because other people do things, but don't truly understand what the true ramifications are of their requests.
Marketing: "What's the big deal? All you have to do is add the 2 or 3 lines of JS to the site."
Devs: "Do you know exactly what that will do?"
Marketing: "It'll give us all sorts of useful metrics for free"
Devs: "Do you know if it is secure or will cause our site to become less secure due to vulns in the included JS? Will it cause the site's performance to become sluggish where we will get blamed? Do you know exactly what data is being collected, and will it affect any of our other obligations of maintaining this site?"
Marketing: "Um..., that's your job. We just want the data"
I'm speaking from the perspective of a site, like Backblaze, where web app and the site fulfill two separate functions. There are lots of cool metrics that marketing wants; any code they put into www.backblaze.com is pretty low cost, and usually done by a separate team than product.
The product site itself (usually app.example.com, but Backblaze seems to use secure.backblaze.com) actually contains customer data in the browser context, is under much higher base resource loads from its core functionality, and is used repeatedly in workflows where poor performance is painful to the user.
No one gives a shit if your pricing page takes 500ms to load instead of 100ms, or if a dozen social media companies who already know where you work learn what kinds of professional products you're looking for.
They do care if a file listing takes longer, a recipe opens slower, if word frequencies in confidential data are leaked to the world.
In most paid products, the non-paid part of a site has radically different performance and security requirements from the paid part, and forcing one to be built to the requirements of the other (in either direction) is wasteful, or dangerous, or both.
This is essentially true for every single human and the reason discussion forums has discussions, because we keep being unable to see the other persons perspective and think we need to spread "the truth" to them.
If you are doing business in the EU, then you have to be careful about using 3rd-party stuff (Google fonts, embedded Youtube videos, embedded maps, chat widgets, ads, pixels, analytics etc. etc.) on the public-facing website as well.
> It's their job, they know what's best.
That's like sending an alcoholic down the spirits aisle.
As long as they don't have the car keys, they can go knock themselves out.
Re: the more substantive legal points - there are off-the-shelf solutions (CMPs, for example) and easy checklists for complying in the setting of a static public-facing website. The web designers and brand managers I've worked with are more than capable of meeting clear industry standards.
It's inside a web app, where customer data is on the page and in JS scopes, where the product team is essential in safeguarding customer data.
> there are off-the-shelf solutions (CMPs, for example) and easy checklists for complying in the setting of a static public-facing website.
In my experience, the people implementing these often don't understand enough about the technology to be allowed to implement this. I wonder if "easy to use" tag managers are to blame, by allowing non-experts to add JS and other includes to webpages without process or scrutiny.
Check a few big brand-name websites, and look at whether they place (third party) cookies before the CMP has even been interacted with.
I can think of some major high street labels where the consent prompt is mere theatre.
> there are off-the-shelf solutions (CMPs, for example) and easy checklists for complying in the setting of a static public-facing website.
Consent Management Platforms, things like Cookiebot?
In my experience, blocking 3rd-party HTTP requests, cookies, LocalStorage access etc. before consent is given – is easy in simple cases, but can quickly get technical and tricky.
I agree with this approach but there's an issue with "it's their job, they know best". They will inevitably want to put the same tracking crap in the logged-in site as well, so they can see how visitors converted into users, how they used the site once they were users, how valuable that made them as customers, and so on. As long as FB/other analytics firm is saying "we can help you market better with additional data", marketers are going to advocate sharing it.
Which is why it has to be a two way street - when it comes to the product, specifically its security and performance, engineering needs to absolutely own the thing.
> Corpweb should be as static as possible, except for whatever third-party JS the marketing professionals think is necessary. It's their job, they know what's best.
I strongly disagree. Marketing professionals often lack technical understanding and are superficial about the consequences. This mentality is how you end up with engineers working for companies doing morally questionable choices because they just want to be a cog in the system instead of being concerned about the direction and how the company do business. Separations between services is a shared illusion, if something is against your values please tell your fellow human beings.
In a static website, where there are standard tools and checklists and web designers to walk them through it, marketing's lack of technical understanding is less of an issue. And in a B2B web app like Backblaze's and my own, the data exposed to the public web site is just not all that sensitive.
And I'm not talking as a prospective employee who "just wants to be a cog in the machine"; I'm talking as a founder and CTO who sets company goals. I'm worried about data leaks caused by poor implementation and short-sightedness, not those caused by company policy that I disagree with. If I disagree with company policy, I change it.
I'd be interested to see a site where marketing professionals with limited technical understanding knocked themselves out, but they used standard tools and checklists, and it came out OK. Do you have any examples?
I agree with this delineation, and if necessary, it lets the sales/marketing people go absolutely wild with the tracking, analytics and CRM-system integration on the public facing marketing website, should the C-level people decide to allow them to do so.
I’m baffled by this mentality but I guess it explains a lot. At which point are you concerned about what other services or even the company is doing? That’s a real slippery slope for me.
* Dealing with sensitive data is their core business, not a side concern. i.e. their customer base is security-conscious enough that they know incompetence on that front will kill their business
* Both of those specific services omit lots of specific identifiers in their data collection, and require you to go out of your way to send truly sensitive stuff to their servers
* By necessity, a technical analytics service gives you lots more control over where exactly it hooks in to your code.
The goal of marketing is to get product in front of the right audience. The proposed solution you mention would include plenty of folks who don’t convert. That would likely create less effective results for marketing.
Also, what would you use to monitor user behavior to improve your product if third party tracking is frowned upon?
> Also, what would you use to monitor user behavior to improve your product if third party tracking is frowned upon?
* user testing, user interviews
* (there's probably a fancy word for this) generate usage metrics from production data. If the product is e.g. a To Do app, you could measure "engagement" by counting how many To Do items each user has created
99% of the time, 1st-party tracking just means hosting the tracking script on their own domain, the data still gets sent to 3rd-party analytics services.
Well, here is where my hot take and general principle needs some nuance :-P
> The proposed solution you mention would include plenty of folks who don’t convert.
The one bit of data I currently have going from the app to corpweb analytics is precisely this - associating a conversion with a website user. That conversion info is sent with hand-coded triggers, the relevant third-party libraries are self-hosted (a good thing generally), and code doesn't call out to it when the user is outside of the billing/subscription flow.
> Also, what would you use to monitor user behavior to improve your product if third party tracking is frowned upon?
I'm open to A/B-testing stuff - the important part in my mind is less specifically about third-party tracking, and more about ensuring that the product/engineering team makes decisions about the product. Pulling third-party code of any kind, but especially tracking code, is a process full of footguns that should be under the control of people who know what they're doing and are empowered to say "no".
I would still be very cautious about giving analytics code full access to all user activity.
Google Analytics custom events and Datadog are in fact the only third-party analytics code I run in my app. Tools like GA that gather less-identifiable user behavior info are borderline in my book between technical and marketing; and I honestly just trust Google as an organization not to mix my own GA data into their marketing data.
Yup! I happen to not do that; part of why I trust Google on this (in the site owner role) is that they're good at making privacy-compromising options clearly-delineated and optional.
Corpweb should be as static as possible, except for whatever third-party JS the marketing professionals think is necessary. It's their job, they know what's best.
Your app should have zero third-party JS except for technical analytics (New Relic, Datadog, whatever).
(This distinction can be fuzzier for free services, and for consumer stuff with non-sensitive data; Backblaze is neither of those.)