How data use restrictions work
Two sets of rules sit on top of any customer data you put into an advertising platform. The first is law — data protection rules in the country your customers live in, which decide whether you may use their details for marketing at all. The second is the platform’s own terms, which you accept every time you upload a customer list or install a tracking pixel, and which are enforceable regardless of what the law in your market allows.
In practice they impose similar demands. You must have collected the data yourself, for a purpose that covers advertising, with the person’s knowledge. Contact details are hashed before they leave your systems, so the platform receives a scrambled value rather than an email address. Purchased, scraped or borrowed lists are not permitted, and neither is passing one client’s data into another client’s account. Certain categories are restricted outright: health conditions, financial detail, religion, sexual orientation, political views, and anything about children. Those must not be uploaded, must not be sent in tracking parameters, and in many cases must not be used to build audiences at all.
Why data use restrictions matter
The visible risk is enforcement. A list rejected at upload is a nuisance; an account restricted for repeated misuse of customer data is a business problem, and a regulator’s interest is a different order of problem again. Between them sits the quiet one: a pixel that sends the wrong parameters can push identifiable or sensitive information into a platform continuously, without anyone noticing, until someone reads the event payload.
There is a commercial reason too. Every restriction here is really a description of what a customer would object to if they saw it. A remittance or clinic audience being retargeted on the basis of what they enquired about is not just a compliance question in Nepal or anywhere else — it is the kind of thing that ends a relationship the first time somebody notices.
Where it goes wrong
The usual failures are ordinary. A spreadsheet of enquiries collected years ago, for a different purpose, gets uploaded as a customer list audience because it was there. A developer adds an email address or an order note to a conversion event so the reporting is richer, and sends personal data into the platform along with it. An agency reuses a lookalike source built from one client for another. A supplier offers a database of leads and somebody buys it.
Deletion is the other blind spot. People who unsubscribe or ask to be removed are taken out of the mailing tool but stay in the uploaded audiences, which continue targeting them long after they asked you to stop.
What to do about it
Write down, once, where each marketing list came from, what people were told when they gave their details, and which audiences it feeds. Hash contact data before upload, keep sensitive categories out of every event and audience, and check what your analytics and tracking setup is actually sending rather than what it was meant to send. Reading the raw event payload once a quarter catches most of these.
Then build removal into the routine: when someone unsubscribes or asks to be deleted, take them out of the uploaded audiences as well as the mailing list, and refresh the lists on a set schedule so old ones stop being used quietly forever.