By 2019, privacy had become part of ordinary website delivery in a way that was difficult to ignore.
The previous year had forced a lot of businesses to think seriously about GDPR, but the practical work did not end once privacy policies were updated. Websites still had analytics scripts, advertising pixels, embedded tools, form tracking, live chat widgets and third-party services setting cookies in the background. The technical side of privacy was now sitting directly inside development decisions.
That changed how I approached website builds. It was no longer enough to ask what a script did for the business. I also wanted to know what it collected, when it loaded, whether it needed consent and whether anyone would remember why it had been added six months later.
After GDPR The Conversation Became Practical
A lot of early privacy conversations were document-led. Businesses needed policies, consent wording and legal reassurance. That work mattered, but it did not automatically change how the website behaved. A privacy policy can say one thing while the page loads half a dozen third-party scripts before the visitor has made any choice.
That gap became the practical problem. Developers had to understand which scripts loaded immediately, which cookies were being created and whether consent tools were actually controlling anything meaningful. A banner that simply says the site uses cookies is not the same as a website that handles consent properly.
This is where privacy started to feel like implementation work rather than wording. The website had to behave in a way that matched what the business was claiming.
Cookies Were No Longer Just A Technical Detail
Cookies used to feel like a small technical detail for many projects. They handled sessions, preferences, analytics and marketing behaviour quietly in the background. In 2019, that background behaviour started becoming more visible because browsers, regulators and users were all paying more attention to tracking.
SameSite cookie changes were part of that wider conversation. They forced developers to think more carefully about whether a cookie was first-party, whether it was being used across sites and whether it needed additional attributes to behave as expected in modern browsers.
Set-Cookie: session_id=abc123; Path=/; SameSite=Lax; Secure; HttpOnlyThat kind of detail matters because authentication, embedded tools and payment flows can all depend on cookies behaving correctly. Privacy changes are not only about advertising. They can affect normal application behaviour if nobody checks the assumptions underneath the site.
Analytics Had To Earn Its Place
Analytics was one of the areas I started questioning more carefully. Most businesses want to understand how their website is being used, and that is reasonable. The problem is that analytics tools can be added casually and then left in place for years without anyone checking whether the information is still being used.
I started asking more direct questions. Who reads this report? Which decisions does it influence? Does the business need individual behaviour tracking, or would aggregate reporting be enough? Is this script slowing the page down? Does it require consent before loading?
Those questions are useful because every third-party script has a cost. It can affect privacy, performance, maintainability and trust. If the data is genuinely useful, that cost may be justified. If nobody can explain why the script is still there, it probably needs removing.
Consent As Part Of User Experience
Consent also became a UX problem. A badly implemented cookie banner can block content, confuse visitors or present choices in a way that is technically available but practically difficult. That is not a good experience, and it does not reflect well on the business.
I wanted consent interfaces to be clear, honest and technically connected to what the site was doing. The visitor should understand the choice being offered. The website should respect that choice. The scripts should behave accordingly. That sounds obvious, but a lot of implementations fail somewhere between those three points.
This work is not particularly glamorous, but it matters because privacy has become part of how people judge digital products. A website that treats consent carelessly feels less trustworthy, even if the design looks polished.
Retrospective Thoughts
Looking at website builds in 2019, I think privacy changed the role of the developer in a useful way. It forced more attention onto the things happening behind the page. Scripts, cookies, requests and embedded services all became part of the project conversation rather than invisible details added near the end.
That is a better way to build websites. Not because every site needs to become paranoid about data, but because every site should understand what it is asking from visitors. If a website collects information, loads third-party tools or tracks behaviour, those decisions should be deliberate. They should not be leftovers from old marketing experiments that nobody remembers.