Privacy first growth: how to personalise with permission

Personalisation still works, the foundation changed

Here is the tension every growth minded developer faces in 2026. Personalisation drives conversions, but the tools the industry used to personalise, third party cookies, tracking people across other people's websites, quiet profiles built from a trail of clicks, are either restricted by the browsers or regulated hard.

The browsers moved first. Safari has capped cookies written by script at seven days since 2019,¹ and has blocked cookies for cross site resources by default since 2020.² Firefox gives every website its own cookie jar by default, so a tracker cannot follow someone from one site to the next.³ Chrome is the exception: Google decided in 2025 to keep its current approach of offering users a choice about third party cookies, and retired most of the Privacy Sandbox technologies that were meant to replace them.⁴ So third party cookies are not dead everywhere. They are simply not something to build a business on.

The law moved too. For an Irish shop, storing or reading anything on a visitor's device needs consent unless a narrow exception applies, under regulation 5(3) of the ePrivacy Regulations 2011.⁵ The regulator is the Data Protection Commission (DPC). The 2011 Regulations still name the Data Protection Commissioner, and the Data Protection Act 2018 transferred all of the Commissioner's functions to the Commission.⁶ Its guidance is clear on the point this article is about: whatever you call a cookie, unless it meets one of the two narrow exemptions it must not be set before the visitor consents, and a cookie that remembers someone's preferences from one visit to the next (the DPC's own example is a travel site's journey planner) needs consent.⁷

The old playbook, track everything, segment later, apologise never, is finished. What has not changed is that people still prefer relevant experiences. They still buy more readily when you show them things they care about, and they still appreciate an email that arrives at the right time with the right offer. The difference is that you have to earn the data now, fair and square.

Throughout I use one invented business. Kilbarry Cycles is an online bike shop in Waterford, run by Eoin, at kilbarrycycles.example. It sells about 2,400 bikes and a few thousand accessories. Nobody real, and every number below is the example's, made up so that every step can be shown.

Why surveillance personalisation was never very good

Before building the alternative, it is worth being honest about why the old approach disappointed, not only legally but practically.

Cross site tracking gave reach, not accuracy. You could follow someone across the web and build a profile, but the profile was full of noise. Someone researching a present for their partner was retargeted for weeks with things they would never buy for themselves. Someone comparing prices on a phone was a different person on a laptop.

And because the data was collected silently, there was no feedback loop. People could not correct a wrong guess. The system optimised for what it inferred from breadcrumbs, not what the person actually wanted.

An example: a visitor reads one Kilbarry article about children's balance bikes, because her nephew has a birthday. Under the old model, she is now "a parent of a toddler" in three ad networks for months. She has no children, she will not buy another balance bike, and nobody asked her. One question, "Who is this for?", would have got it right in a second.

Three layers replace the old stack

The replacement is not one tool. It is three layers working together, each depending on the one beneath it.

Read it top to bottom. Consent sits first because everything else reads from it. Collection sits second because it is where most shops leak: a tag that fires before the visitor chose is a problem no amount of clever modelling fixes later. And the decision near the bottom never ends in nothing: someone who says no still gets a shop that works and adapts to what they are doing right now.

Let me walk through each layer.

Layer one: consent that actually does what it says

Most consent implementations are theatre. A banner appears, the visitor presses "accept all" because it is the quickest way to the page, and the business calls that informed consent. Or the reject button is harder to find than the accept button, which is exactly what the DPC's guidance rules out: a reject option must get the same prominence as accept, no box or slider may be set to on in advance, and withdrawing must be as easy as giving.⁷

The test a regulator applies is whether the mechanism does what it says. Does every tag stop when someone presses reject? Is the choice honoured on the next page, and the one after? Here is how I handle consent state in Rails:

module ConsentManagement
  class ConsentState
    PURPOSES = {
      essential:       { requires_consent: false }, # login, basket, security
      analytics:       { requires_consent: true },  # how the shop is used, in aggregate
      personalisation: { requires_consent: true },  # content chosen from interests or behaviour
      advertising:     { requires_consent: true }   # ad measurement and audiences
    }.freeze

    # Google consent mode parameters each purpose controls
    CONSENT_MODE_MAP = {
      analytics:       [:analytics_storage],
      personalisation: [:personalization_storage],
      advertising:     [:ad_storage, :ad_user_data, :ad_personalization]
    }.freeze

    def initialize(record)
      @record = record # the latest ConsentRecord, or nil if no choice yet
    end

    def granted?(purpose)
      return true unless PURPOSES.dig(purpose, :requires_consent)
      return false unless @record # no choice yet means no

      @record.granted_purposes.include?(purpose.to_s)
    end

    def google_consent_signals
      signals = { security_storage: "granted", functionality_storage: "granted" }
      CONSENT_MODE_MAP.each do |purpose, keys|
        keys.each { |key| signals[key] = granted?(purpose) ? "granted" : "denied" }
      end
      signals
    end
  end
end

Each record stores what was granted, what was refused, where the choice was made (the banner or the preference centre), the version of the wording shown and the time. The critical detail is that consent is checked when something runs, not only when data is collected. A choice can be withdrawn at any moment, and the system has to respect that on the very next request.

The original version of this article handled Austria, Germany and Switzerland with different defaults. For an Irish shop there is one rule: no choice yet means no. How the German speaking markets differ is in cookies, consent and tracking for DACH.

Worked example: one visitor's choice at Kilbarry

A visitor arrives from a search for "gravel bike under €1,500". The banner offers four switches, all off, with "accept all" and "reject all" side by side and the same size. She switches on personalisation and leaves the rest off.

Her record: granted personalisation, refused analytics and advertising, source banner, wording version 7, 10.42am. Calling granted?(:personalisation) returns true, granted?(:advertising) returns false. The consent mode signals sent to Google's tag say personalization_storage granted, and ad_storage, ad_user_data, ad_personalization and analytics_storage denied. Two days later she opens the preference centre from the footer and switches personalisation off. The next page she loads shows the contextual version, and the engine never reads her history again.

Consent mode carries the choice to Google's tags

If you use Google's tags, consent mode is how the choice reaches them. It has seven parameters: ad_storage, analytics_storage, ad_user_data, ad_personalization, functionality_storage, personalization_storage and security_storage.⁸

It comes in two shapes. In basic mode, Google's tags are blocked until the visitor makes a choice, and if they refuse, nothing is sent at all. In advanced mode, the tags load straight away with consent defaulting to denied, and while it is denied they send cookieless measurements that Google uses to model what it cannot observe.⁸ The original version of this article said advanced mode "recovers 10 to 20% of your attribution data". I could not find a source for that figure, so it is gone. Whether advanced mode suits an Irish shop at all is a judgement for the business and its adviser, which I take apart in event tracking and consent mode.

The default, set before any Google tag loads, is the same for every visitor to an Irish shop:

window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}

gtag('consent', 'default', {
  'ad_storage': 'denied',
  'analytics_storage': 'denied',
  'ad_user_data': 'denied',
  'ad_personalization': 'denied',
  'personalization_storage': 'denied',
  'functionality_storage': 'granted',
  'security_storage': 'granted',
  'wait_for_update': 500
});

An example: the visitor from the last section loads her first page at 10.41am, before touching the banner. The default above runs first, so Google's tags start with everything denied apart from functionality and security storage. At 10.42am she switches on personalisation, and the shop calls gtag('consent', 'update', ...) with the signals from google_consent_signals. Only personalization_storage changes to granted. Advertising stays denied, so no advertising cookie is written and no remarketing list ever hears of her.

Layer two: collection on your own server

Client side tracking means every vendor's script runs in the visitor's browser and sends data to the vendor's own domain. You have little control over what each script collects, and every one of them costs page speed.

Server side collection flips this. The browser sends events to your own server. Your server decides what each destination may receive, strips what it should not see and forwards the rest. The benefits are real:

• Control. Your server decides which fields reach which vendor. An email address can be withheld, or hashed and sent only where advertising consent exists.
• Speed. One small script on the page instead of a dozen vendor tags.
• Enforcement in one place. The consent check runs once, on the server, before anything is forwarded.

What server side does not do is change the law. The DPC says the rule applies to any storage on or access to the device, whatever the technology, and that visitors must be told about the third parties who receive the data when they are asked to consent.⁷ A setup that forwards refused visitors to an ad platform because the pixel no longer runs in the browser has not solved a problem, it has hidden one. The same goes for ad blockers: a first party endpoint is blocked less often, but a visitor who blocks tracking has made a choice, and the consent check still applies to them.

module ServerSideTracking
  class EventProcessor
    def process(event:, consent:, user:)
      return unless valid?(event)

      event = event.merge(event_id: event[:event_id] || SecureRandom.uuid) # shared with the browser for deduplication
      destinations(consent).each { |d| d.forward!(payload_for(d, event, user, consent)) }
      InternalCounts.increment!(event[:name]) # an aggregate count, no user, no session
    end

    private

    def destinations(consent)
      list = []
      list << GA4Forwarder.new if consent.granted?(:analytics)
      list << MetaCapiForwarder.new << GoogleAdsForwarder.new if consent.granted?(:advertising)
      list
    end

    def payload_for(destination, event, user, consent)
      base = event.slice(:name, :event_id, :value, :currency, :occurred_at)
      return base unless destination.advertising? && consent.granted?(:advertising)

      base.merge(hashed_email: Digest::SHA256.hexdigest(user.email.strip.downcase))
    end
  end
end

Meta's Conversions API, the server side route into Meta, deduplicates a browser pixel event and a server event when both carry the same event name and the same event id, generally keeping the first to arrive, within 48 hours.⁹ That is why the processor passes the browser's event_id through rather than inventing a new one.

The original article reported that on a marketplace I built, the server side Conversions API recovered roughly 25% to 30% of the conversions the browser pixel missed. That was my observation on that one product, not a general figure. Everything recovered that way still had advertising consent behind it.

Worked example: one order, three destinations

A customer who granted analytics but refused advertising buys a €1,240 gravel bike. The browser sends purchase with event id a1f3, value 1240 and currency EUR to collect.kilbarrycycles.example. The server validates it, checks consent, and finds analytics granted and advertising refused. So GA4 receives the purchase with its value and nothing else. Meta and Google Ads receive nothing. The internal counter for purchases goes up by one. The order itself is in the shop's database regardless, because delivering it is the contract, not tracking.

Layer three: data people give you on purpose

This is the layer that does the work. Once consent and collection are sound, the question becomes: what data do you actually need, and how do you get people to share it willingly?

Zero party data is what people tell you on purpose: preferences, sizes, budgets, what a purchase is for. It is the most reliable signal there is, because the person said it, and they said it so that you would use it.

First party data is what you observe on your own shop with permission: product views, searches, orders, email clicks.

Second party data is another business's first party data shared under an agreement. Useful occasionally, and it needs a proper data sharing contract and a lawful basis on both sides.

Third party data is collected by companies with no relationship with the person at all. That is the part that is fading, and good riddance.

The strategy follows: collect as much zero party and first party data as people are happy to give, through a fair exchange, and build every personalisation decision on that.

Ask for preferences where the answer pays off at once

The original article described four products I have worked on, each collecting zero party data a different way: a vehicle finder quiz on a marketplace, a goal setting step in a campaign tool's onboarding, an email preference centre, and interest tags on a local directory. All four patterns transfer to a shop.

A finder quiz. Four quick questions that cut a big catalogue down to a shortlist.

A preference centre. Not just "unsubscribe", but a page where people choose topics, frequency and channels.

Interest tags. A few taps on the account page that decide what the homepage leads with.

A goal at onboarding. For a software product, the customer's own target, so the product can optimise towards what they called success.

Here is the quiz collector:

module ZeroPartyData
  class PreferenceCollector
    def collect_from_quiz(user:, responses:)
      responses.each do |question, answer|
        UserPreference.create!(
          user: user,
          key: question.key,
          value: answer,
          source: :finder_quiz,
          shared_at: Time.current,
          expires_at: 12.months.from_now # preferences age out
        )
      end
      PersonalisationEngine.refresh_profile(user)
    end
  end
end

The value exchange is what makes it work, and the rules are simple:

1. Ask at the right moment. Not a 20 question survey at the door. Ask for a budget when someone is about to browse bikes.
2. Show the payoff at once. The very next screen should use the answer. If people share and nothing changes, they never share again.
3. Keep it short. One or two questions at a time. Asking a little over several visits beats a long form on day one.
4. Make it easy to change. Preferences are editable at any time, and they expire.
5. Say why you are asking. "Four questions, so I can show you bikes that fit how you ride" is honest and motivating.

Worked example: the finder quiz at Kilbarry

Eoin's quiz asks four things: what the bike is for (commuting, gravel, road, family), budget (under €800, €800 to €1,500, over €1,500), height in bands, and whether electric assistance matters. A visitor answers gravel, €800 to €1,500, 175 to 185cm, no electric.

The filter runs on the catalogue: 2,400 bikes, of which 310 are gravel, of which 96 sit in the budget, of which 41 come in a size for that height band, of which 18 have no motor. The next screen shows those 18, sorted by stock. Four rows go into user_preferences, each expiring in twelve months. Because she asked for the shortlist, the result is the service she requested. She can edit or delete every answer from her account page.

Behaviour needs its own yes

Beyond what people tell you, what they do on your shop is the second best signal. It also needs care, because using it is profiling: the GDPR defines profiling as using personal data to analyse or predict things such as someone's preferences, interests or behaviour.¹⁰

The original version of this article tied behavioural personalisation to analytics consent. That was wrong. Analytics is about how the shop is used in aggregate. Choosing what one person sees from their history is personalisation, and the DPC's guidance leaves no exemption for it: only the communications and strictly necessary exemptions escape consent, and remembering someone's interests to choose what they see is neither.⁷ So behaviour is used only with the personalisation yes, the same rule as in building custom AI recommendations in Solidus.

The event schema keeps that honest:

module Analytics
  class EventSchema
    EVENTS = {
      page_view:     { properties: %i[page_path], consent: :analytics },
      search:        { properties: %i[query results_count], consent: :personalisation },
      product_view:  { properties: %i[product_id price currency], consent: :personalisation },
      add_to_cart:   { properties: %i[product_id quantity value currency], consent: :personalisation },
      email_click:   { properties: %i[campaign_id link_id], consent: :personalisation }
    }.freeze

    def self.track(name, properties:, user:, consent:)
      schema = EVENTS[name]
      return unless schema && consent.granted?(schema[:consent])

      Event.create!(name: name, user_id: user&.id, properties: properties.slice(*schema[:properties]), recorded_at: Time.current)
    end
  end
end

Two changes from the original. Email opens are gone: Apple's Mail Privacy Protection fetches remote content, including the invisible image that records an open, in the background whether or not anyone reads the message, so an open is not something a person did.¹¹ A click is. And preference_updated is no longer an event at all: the preference row itself is the record.

People can also object to profiling used for direct marketing at any time, and then it stops.¹² And the data has to be limited to what the purpose needs and kept no longer than necessary.¹³ That is why the schema records five events with a handful of fields each, and nothing more.

An example: a visitor who granted personalisation views three gravel bikes and searches "tubeless tyres". Four rows are written. A visitor who granted only analytics views the same three bikes: three page_view rows with the path, no user id in the profile, and nothing the engine can use to personalise. A visitor who refused everything: no rows at all.

The engine picks the richest experience each person allows

With the three layers in place, the personalisation engine has clean, consented data to work with, and it degrades gracefully instead of being all or nothing.

module Personalisation
  class Engine
    def personalise(user:, context:, consent:)
      profile = PersonalisationProfile.new
      profile.merge_context(page: context[:page], query: context[:query], month: Date.current.month)

      if user && consent.granted?(:personalisation)
        profile.merge_preferences(user.active_preferences) # what they told you
        profile.merge_behaviour(views: user.recent_product_views(30.days), searches: user.recent_searches(30.days))
      end

      Ranker.for(context[:surface]).rank(profile)
    end
  end
end

The profile builds from three kinds of signal:

1. Context, for everyone: the page they are on, what they just typed, the time of year. It comes from the current request, nothing is stored on the device to build it, and nothing is remembered afterwards. If a contextual signal ever needs a stored identifier, it has stopped being contextual.
2. Stated preferences, for signed in customers who said yes: the quiz answers and interest tags.
3. Behaviour, under the same yes: recent views and searches, thirty days at most.

Worked example: three visitors on a Saturday morning

Visitor one refused everything and is browsing the gravel category in March. The engine knows the page and the month, so the category leads with spring gravel bikes and the accessories block shows mudguards and lights, the same for everyone in that category.

Visitor two is signed in, said yes, and took the quiz: gravel, €800 to €1,500, no electric. The homepage opens on her 18 shortlisted bikes, with two new arrivals that match.

Visitor three said yes but never took the quiz. In the last week he viewed four road bikes around €2,000 and searched "carbon wheels". The homepage leads with road bikes in that range and a wheel upgrade guide.

Three visitors, three honest experiences, and nobody was followed anywhere they did not choose to go.

Emails need the right permission, including the friendly ones

Personalised email has its own rules on top of all this. Under regulation 13 of the ePrivacy Regulations 2011, marketing email to an individual needs their consent, or, for your own customers, the exception in regulation 13(11): your own products of a kind similar to what they bought, an easy and free way to object when you took the address and in every message since, and a sale no more than 12 months before the email, unless you have emailed them under it within that time.⁵

The trap is the friendly email. "Tell us how we did" and "update your preferences" feel like service, and sometimes they are. The DPC has looked at exactly this. An airline emailed a passenger asking for feedback on a recent trip, and the DPC said correspondence "sent solely for informational or feedback purposes does not constitute direct marketing", while one that included marketing content could be, and would need an unsubscribe option. It also described direct marketing as communications aimed at promoting a product or service or encouraging further enquiries. That email passed because it only sought feedback to improve the service.¹⁴ So a feedback email sent to win a drifting customer back, with a product row underneath, is marketing. A plain question about a recent order, with no offer and no product, may not be. The safe course is to send anything with a commercial purpose only to people who allowed marketing or fall under the regulation 13(11) exception, which is the same line I draw in AI powered marketing automation.

An example: Eoin wants to email 900 customers who bought a bike last spring and have not been back. 600 allowed marketing, or bought recently enough for the regulation 13(11) exception to cover them, and never objected. They get a service reminder for the bike plus a personalised accessories row, with an unsubscribe link. The other 300 get nothing promotional. If Eoin sends them anything, it is a plain "how are you getting on with the bike?" with no products, no discount and no request for a review he will use in adverts.

Does privacy first actually perform?

The honest answer: it works differently, and in my experience mostly better.

What I have observed across the products I have built:

Stated preferences beat inferred ones. People who actively shared preferences engaged at roughly two to three times the rate of people who were profiled passively under the old model. That is my observation, not a published study, and it makes sense: they told you what they want.

Consented lists deliver better. Consent based sending means cleaner lists and fewer complaints, and deliverability improved noticeably after moving to strictly consented sends.

Cleaner attribution. Server side collection with proper deduplication gave numbers I could trust more, because what came through was complete and counted once.

The mechanism I believe sits behind it is a loop of trust. Transparent consent builds trust. Trust makes people more willing to share. More shared data allows better personalisation. Better personalisation reinforces trust. It is my reading of what I have seen, not a law of nature, and it only turns if the first step is honest.

An example: suppose Kilbarry has 10,000 visitors a month and, as the example's assumption, 45% say yes to personalisation. That is 4,500 people with a personal experience and 5,500 with a contextual one. If the shop then adds a clear preference centre and the yes rate rises to 50%, another 500 people a month get the personal version, without a single extra tracker.

The privacy first checklist

1. Audit what fires, and where it goes. If you cannot answer precisely, you are not in control.
2. Make the banner honest, set consent mode defaults to denied, and choose basic or advanced mode knowingly.
3. Collect on your own server if you need the control, with the same consent state.
4. Build the zero party programme, each question paying off on the next screen.
5. Keep the event schema thin, behaviour only under the personalisation yes.
6. Check every email's purpose before choosing who gets it.

For the deeper plumbing, read server side tracking, GDPR compliant AI features and what the right to be forgotten means for models. None of this is legal advice, and for anything beyond a small shop an hour with a solicitor is money well spent.

The bottom line

Privacy first growth is not a contradiction. It is the only approach that does not break every time a browser updates or a regulator publishes new guidance.

It takes more engineering up front: consent that works, collection you control, and data people give you on purpose. The result is personalisation that gets better as people trust you with more, instead of worse every time a browser closes another gap. Earn the data. Personalise with permission.

Sources

Footnotes

1. John Wilander, Intelligent Tracking Prevention 2.1, WebKit, 21 February 2019, https://webkit.org/blog/8613/intelligent-tracking-prevention-2-1/

2. John Wilander, Full Third Party Cookie Blocking and More, WebKit, 24 March 2020, https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/

3. Mozilla, Firefox rolls out Total Cookie Protection by default to more users worldwide, The Mozilla Blog, 14 June 2022, updated 28 August 2024, https://blog.mozilla.org/en/mozilla/firefox-rolls-out-total-cookie-protection-by-default-to-all-users-worldwide/

4. Anthony Chavez, Update on plans for Privacy Sandbox technologies, Google, 17 October 2025, https://privacysandbox.google.com/blog/update-on-plans-for-privacy-sandbox-technologies

5. European Communities (Electronic Communications Networks and Services) (Privacy and Electronic Communications) Regulations 2011, S.I. No. 336 of 2011, regulations 5(3), 5(5) and 13(1) and (11), Irish Statute Book, 2011, https://www.irishstatutebook.ie/eli/2011/si/336/made/en/print

6. Data Protection Act 2018, section 14, transfer of functions of Data Protection Commissioner to Commission, Irish Statute Book, 2018, https://www.irishstatutebook.ie/eli/2018/act/7/enacted/en/print

7. Data Protection Commission, Guidance note: Cookies and other tracking technologies, DPC, 2020, https://www.dataprotection.ie/sites/default/files/uploads/2020-04/Guidance%20note%20on%20cookies%20and%20other%20tracking%20technologies.pdf

8. Google, Consent mode overview, Google for Developers, Tag Platform, https://developers.google.com/tag-platform/security/concepts/consent-mode

9. Meta, Handling duplicate Pixel and Conversions API events, Marketing API documentation, Meta for Developers, https://developers.facebook.com/docs/marketing-api/conversions-api/deduplicate-pixel-and-server-events

10. Regulation (EU) 2016/679 (General Data Protection Regulation), Article 4, definitions, point 4 (profiling), EUR-Lex, https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679

11. Apple, Mail Privacy Protection and privacy, Apple Legal, https://www.apple.com/legal/privacy/data/en/mail-privacy-protection/

12. Regulation (EU) 2016/679 (General Data Protection Regulation), Article 21(2) and (3), right to object, EUR-Lex, https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679

13. Regulation (EU) 2016/679 (General Data Protection Regulation), Article 5(1)(c) and (e), principles, EUR-Lex, https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679

14. Data Protection Commission, Direct Marketing, case study on an airline feedback email, dataprotection.ie, 2024, https://www.dataprotection.ie/en/dpc-guidance/case-studies/electronic-direct-marketing/direct-marketing