Product feed software: UK consent, records and transfers

What to take away

Product feed software that builds audiences, retargets shoppers or scores customers is doing personal data processing, so it needs a lawful basis under UK GDPR like any other marketing system.
The ICO expects you to choose that basis before you start, document it, and tell people about it in your privacy information.
Consent under PECR is a separate test from a UK GDPR lawful basis, and it applies to cookies, pixels and similar storage or access technologies, not to everything else.
Audience research, including surveys and panel work run through feed tools, is processing too, and it needs the same paperwork as live targeting.
Sending feed data to a platform or research vendor abroad needs a transfer mechanism, not just a contract clause in a settings page.

UK GDPR and the ICO rules that touch feed personalisation

In the UK, the body responsible for overseeing data protection is the ICO. It covers how businesses across England, Scotland and Wales handle personal data, and it applies to you regardless of where your feed tool is hosted.

The UK GDPR and the Data Protection Act 2018 govern the processing of personal data. A product feed is not automatically personal data, but matching a feed to a customer, building a lookalike audience, excluding previous buyers or tracking a click back to a person involves personal data processing. For example, that applies when a retailer uses product feed software such as Channable or Feedonomics to match catalogue data with identifiable customer records.

The ICO publishes the working guidance you will actually use. Its UK GDPR guidance and resources set out the principles, the individual rights and the accountability duties that sit behind feed personalisation.

Accountability is the part retailers underestimate. You must be able to show how you comply, not simply assert that you do. That means written decisions, not a verbal agreement in a planning meeting.

Three ICO themes bite hardest on feed work. Data minimisation, because feeds often carry more attributes than the campaign needs. Transparency, because shoppers rarely know their browsing history shaped the feed. Retention, because audience segments tend to live forever unless someone deletes them.

Marketplace feeds add a layer. Amazon UK Seller Central and eBay UK both run their own advertising systems, but controller roles depend on who determines the purposes and means of each processing activity. Do not assume the retailer is controller for every use of data sent to a platform. The same role-mapping question applies to Google Shopping.

The CMA watches how online retailers use urgency claims, rankings and personalised offers. That is consumer law, not data protection, but the two collide when a personalised feed drives a price or availability claim.

Where feed personalisation stops being anonymous

Aggregate reporting is generally not personal data. Segment-level counts usually are not either, provided the segment is large enough that no individual can be singled out.

Personalisation crosses the line when the output is aimed at one person. A feed that suppresses a product for a named customer, or bids differently for a known visitor, is personal data processing.

Pseudonymous identifiers count. A hashed email or a device ID is still personal data if you or anyone else can link it back to a person.

What the ICO expects to see in practice

A short written note per campaign covering the basis, the data used, the retention period and who receives the data. This is the core of shopping feeds data protection work, and it is not onerous once templated.

A privacy notice that names the categories of data and the purposes. Generic notices that mention marketing in one line fail the transparency test when feeds are doing the targeting.

A named owner. Someone in the business has to be answerable for feed data decisions, even if the tooling sits with an agency.

Choosing a lawful basis for feed targeting and audience research

You need a lawful basis for every processing purpose under UK GDPR. The six lawful bases are consent, contract, legal obligation, vital interests, public task and legitimate interests. The ICO's Guide to the UK GDPR explains how each basis works and what it obliges you to do.

Choosing a lawful basis

What is the feed targeting purpose?

Yes

Suppression or frequency capping -> Legitimate interests

Basic segmentation of own customers -> Legitimate interests

For feed targeting, the realistic options are legitimate interests and consent. Contract is a poor fit, because a shopper buying a coat has not asked you to retarget them for six weeks.

Legitimate interests suits suppression and frequency capping. You are using data to avoid annoying people, which is easy to justify and easy to explain.

Legitimate interests also suits basic segmentation of your own customers, such as separating trade buyers from consumers for a feed that prices differently.

Consent is the safer route when the targeting is intrusive, when you are using third-party data, or when the audience includes special category data inferred from browsing.

The ICO's direct marketing guidance is the reference point here. It deals with electronic marketing specifically, which is where most feed retargeting lands.

Legitimate interests in three steps

Identify the interest. Write one sentencefor example, recovering abandoned baskets for existing customers.
Run the balancing test. Set out why the interest is not overridden by the shopper's rights, and note any safeguards such as a 30-day cap.
Publish it. Add the purpose and the basis to your privacy notice and give a simple route to object.

If you cannot complete step two honestly, the basis is wrong and you should move to consent.

Audience research is a different purpose

Research has its own basis. If you survey customers about why they bought, that is usually legitimate interests or, where the survey is optional and incentivised, consent.

If you scrape reviews or social posts into a research tool, you are processing personal data unless it is genuinely anonymised. Most tools do not anonymise.

Mixing purposes is the common failure. A single basis cannot cover targeting, research and analytics at once. Document each separately, and keep the research data out of the live targeting feed.

Running research before you scale spend is its own discipline, and the sequencing matters as much as the legal basis. shopping feeds audience research covers when a study is worth the cost and when it is not.

Building personas without breaking the rules

Personas are usually aggregated and therefore low risk. The risk appears when a persona is built from a small sample, or from a segment so narrow that individuals are identifiable.

Set a minimum segment size in the tool and enforce it. If a persona rests on twelve people in one Welsh postcode, treat it as personal data.

The practical route from research to targeting is set out in shopping feeds buyer personas, which covers turning interview themes into feed rules without carrying personal data across.

Consent, cookies and storage technologies in product feed software

Consent under the Privacy and Electronic Communications (EC Directive) Regulations 2003 (PECR) is not the same as consent under UK GDPR, though the standard is aligned. PECR governs cookies and similar technologies that store or access information on a user's device.

Valid consent requirements

Freely given, no pre-ticked boxes
Specific to each purpose
Knowingly given, not continued browsing
Unambiguous, accept and reject offered
Granularanalytics yes, advertising no
Withdrawal as easy as giving consent

The PECR test is whether a technology stores information on a user's device or accesses information stored there. A technology's label, or whether it runs in a browser or server-side, does not decide the issue; assess what it actually does.

If your product feed software uses a pixel that stores information on or accesses information stored on a user's device to build a retargeting audience, PECR consent is required before that storage or access unless a strictly necessary exemption applies.

Strictly necessary is narrow. It covers things like remembering a basket or a security token. It does not cover analytics, attribution or audience building, however useful those are.

What valid consent looks like

It is necessary for consent to be given freely, specifically, knowingly and without any ambiguity. A pre-ticked box fails. A banner that only offers accept fails. Continued browsing is not consent.

Granularity matters. If a shopper agrees to analytics but not to advertising, the advertising pixel must not fire. Most consent platforms can do this; most feed integrations are not configured for it.

Withdrawal must be as easy as giving consent. If the accept button is on the banner, the reject or withdraw route should be equally visible, not buried three clicks into a preference centre.

Server-side tagging and the consent boundary

Moving a pixel server-side does not remove the consent requirement. The test is whether you store or access information on the device, not where the code runs.

Server-side tagging can reduce data leakage and improve measurement accuracy. It does not change the legal position.

A pre-launch checklist for feed tracking

Every pixel, tag and SDK in the feed stack listed with its purpose and its consent category.
Consent banner configured to block non-essential tags before they fire.
Reject option as prominent as accept.
Consent records stored with a timestamp, the choices made and the banner version shown.
Withdrawal route tested end to end, including how it propagates to the feed platform.
Strictly necessary tags documented with the reason each one qualifies.
Consent refresh period agreed, and a re-prompt scheduled.

Keep the consent record. If the ICO asks, a log showing who consented to what, and when, is the difference between a compliant process and an assertion.

Record keeping and ICO registration for retailers

Record keeping is a UK GDPR obligation, not optional good practice. Article 30 records of processing are required for most organisations, with a lighter regime for smaller businesses.

Your feed work should appear in those records. A single line saying marketing does not describe what a feed platform receives.

Record-keeping steps

Article 30 record-keeping steps

List every feed destination
Note data categories, purpose, lawful basis, retention
Note transfer mechanism for non-UK destinations
Name internal owner and last review date
Store record where it can be produced quickly
Review quarterly and on new feeds

A spreadsheet is enough. The ICO does not require a particular format, only that the record exists and is accurate.

Retention is where records and reality diverge. If the record says 90 days but the audience segment has been live for two years, the record is wrong and so is the processing.

ICO registration details

Use the ICO's data protection fee self-assessment to check whether your organisation must pay or qualifies for an exemption. If required to pay, follow the ICO's registration and payment process, then check the ICO's data protection fee register to confirm your details are current. If your business moved address, changed name or restructured through Companies House, update the ICO record too.

Keep VAT compliance separate from data protection

VAT treatment in product feeds is a separate pricing-compliance question, not a data-protection lawful basis.

It becomes relevant to this article when a personalised price is linked to an identifiable shopper; assess the data processing separately from whether the price is accurate.

International transfers when feeds and research tools sit abroad

Many feed platforms and research tools are hosted outside the UK. Sending personal data to them is a restricted transfer.

International transfer routes

Is the destination country covered by UK adequacy?

Yes

Transfer proceeds without extra paperwork

Check UK Extension to EU-US Data Privacy Framework

The UK has adequacy regulations for the EEA and a list of other countries. If the destination is covered, the transfer can proceed without extra paperwork.

The US is the awkward case. The UK Extension to the EU-US Data Privacy Framework allows transfers to certified US organisations without a separate transfer mechanism.

Check the certification. It is organisation-specific, and a parent company's certification does not automatically cover a subsidiary.

When adequacy does not apply

You need an appropriate safeguard. The International Data Transfer Agreement, or the Addendum to the EU standard contractual clauses, are the usual routes.

A transfer risk assessment sits alongside the safeguard. It is a written look at what happens to the data in the destination country and what you have done to reduce the risk.

Most feed vendors will hand you a signed IDTA and a completed assessment. Read them. The assessment should describe your data, not a generic template.

Practical steps for feed stacks

Confirm where each vendor stores and processes data, not just where it is headquartered.
Ask for the sub-processor list and check it against the countries you have assessed.
Keep the transfer mechanism on file with the Article 30 record for that vendor.
Re-check annually, and whenever a vendor changes hosting region.
Note any onward transfers, because a vendor using a sub-processor in another country creates a second transfer.

If a vendor cannot say where the data goes, that is the answer. Move the feed or move the data.

Common questions

Do I need consent to personalise a product feed?

Not always. If the personalisation uses your own customer data and does not involve storing or reading information on a device, legitimate interests can work. If a pixel or cookie is involved, PECR consent applies first.

Is a lawful basis the same as consent?

No. Under UK GDPR, there are six lawful bases, and consent is one of them. Choosing legitimate interests instead means you must run a balancing test and offer a right to object.

Do I have to pay the ICO data protection fee if I only run feeds?

Whether you must pay depends on your organisation's processing and whether an exemption applies; using product feed software alone does not decide it. Use the ICO's data protection fee self-assessment to check your position. If it says you must pay, follow the ICO's registration and payment process and check the public data protection fee register for your entry.

Can I use the same basis for targeting and for audience research?

No. They are separate purposes with different expectations. Document each one, and keep research data out of the live targeting feed.

What records do I actually need to keep?

An Article 30 record covering each feed destination, the data sent, the purpose, the basis, retention and any transfer mechanism. A maintained spreadsheet is sufficient.

What happens if a vendor hosts our feed data in the US?

Check whether the vendor is certified under the UK Extension to the EU-US Data Privacy Framework. If not, you need an IDTA or the Addendum plus a transfer risk assessment.