Cum am conectat WooCommerce la Google Ads Customer Match cu n8n, automat, înainte de Black Friday

Lista de cumpărători din contul de Google Ads avea 0 membri. Nu pentru că magazinul nu avea clienți, ci pentru că lista fusese încărcată o dată, manual, dintr-un CSV, și apoi uitată. Membrii expiraseră. Cu o lună înainte de Black Friday, campaniile Performance Max porneau fără să știe cine a mai cumpărat din magazin.

E vorba de un magazin online de produse naturale, cu comenzi zilnice și clienți care revin. Mai jos e tot procesul: arhitectura, pașii, regulile de normalizare, ce a picat la primul test și ce trebuie să scrie în politica de confidențialitate.

Ce este Customer Match, pe scurt

Customer Match este funcția din Google Ads prin care încarci date de clienți (email, telefon, nume și adresă) ca să creezi o listă de audiență. Google potrivește datele hash-uite cu conturile Google și afișează reclame membrilor listei în Search, în tab-ul Shopping, pe YouTube, în Gmail și în rețeaua Display. În Performance Max și Demand Gen, lista lucrează ca semnal de audiență.

Pentru un magazin online, lista de cumpărători e cel mai puternic semnal primar pe care îl poți da algoritmului. Spune exact cine a cumpărat deja, nu cine a vizitat o pagină.

De ce nu ajunge un CSV încărcat manual

Automatizarea rezolvă toate patru: lista se actualizează la fiecare comandă, durata de membru se reîmprospătează la fiecare cumpărare nouă, iar datele pleacă din n8n doar hash-uite.

De ce Data Manager API, nu Google Ads API

Google a lansat Data Manager API în decembrie 2025, ca punct unic de intrare pentru datele first-party. De la 1 aprilie 2026, cererile Customer Match către OfflineUserDataJobService și UserDataService din Google Ads API eșuează cu eroarea CUSTOMER_NOT_ALLOWLISTED_FOR_THIS_FEATURE pentru developer token-urile (azi înlocuite de proiectele Google Cloud) care nu au trimis cereri Customer Match între 1 octombrie 2025 și 31 martie 2026.

Pe scurt: dacă pornești acum o integrare nouă, o faci pe Data Manager API. Restul Google Ads API (campanii, raportare, licitare) nu e afectat.

Ce trebuie știut despre Data Manager API:

• Autentificare OAuth 2.0, cu scope-ul https://www.googleapis.com/auth/datamanager.
• Endpoint-ul pentru liste: POST https://datamanager.googleapis.com/v1/audienceMembers:ingest.
• Până la 10.000 de membri pe cerere și până la 10 identificatori pe membru.
• Câmpul validateOnly validează cererea fără să adauge nimic. E modul de test.
• Termenii Customer Match trebuie acceptați explicit în cerere (termsOfService).

Arhitectura

WooCommerce (order.updated)
        ↓
n8n: filtru status = completed
        ↓
n8n: normalizare + SHA-256 + deduplicare + loturi de 10.000
        ↓
Data Manager API: audienceMembers:ingest
        ↓
Google Ads: lista „Cumpărători”

Plus o ramură separată, rulată o singură dată, pentru importul istoric. Totul rulează pe o instanță n8n self-hosted, deci datele clienților nu trec printr-un serviciu terț de automatizare.

Pașii, unul câte unul

1. Pregătești lista în Google Ads

În Audience manager creezi o listă de tip „Customer list”, cu durata de membru de 540 de zile. Notezi ID-ul listei. Verifici că contul e eligibil pentru Customer Match: Google cere un istoric bun de conformitate cu politicile și de plăți.

Dacă vrei să excluzi clienții recenți din prospectare, o a doua listă cu durata de 30 de zile face treaba singură: fiecare comandă nouă reîmprospătează durata, iar cine nu mai cumpără iese din listă.

2. Activezi Data Manager API și creezi credențiala OAuth

În Google Cloud activezi Data Manager API în proiectul în care ai clientul OAuth. În n8n creezi o credențială OAuth2 generică, cu scope-ul datamanager și parametrii access_type=offline&prompt=consent, ca să primești refresh token. Te conectezi cu un cont Google care are acces la contul de Google Ads.

3. Triggerul: comanda finalizată

WooCommerce nu are un eveniment de webhook separat pentru „comandă finalizată”. Folosești order.updated și filtrezi în n8n pe status = completed. Comenzile în procesare, anulate sau eșuate nu trec mai departe.

order.updated se declanșează de mai multe ori pe aceeași comandă. Nu e o problemă: aceeași persoană retrimisă nu se dublează în listă.

4. Normalizarea și hash-ul

Aici se câștigă sau se pierde rata de potrivire. Google acceptă și date formatate greșit, dar nu le potrivește cu nimic.

După normalizare, fiecare valoare se codifică UTF-8 și se hash-uiește cu SHA-256, rezultatul fiind un șir hex de 64 de caractere, cu litere mici. Am scris funcția SHA-256 în JavaScript simplu, direct în Code node, ca să nu depind de modulul crypto, care pe multe instanțe n8n e blocat implicit.

Tot în acest pas: deduplicare după email sau telefon și împărțire în loturi de maximum 10.000 de membri.

5. Trimiterea în Google Ads

Un nod HTTP Request trimite fiecare lot la audienceMembers:ingest, cu trei reîncercări la eroare. Corpul cererii are destinația (contul de Google Ads și ID-ul listei), membrii cu identificatorii hash-uiți, semnalele de consimțământ, encoding-ul HEX și acceptarea termenilor Customer Match.

6. Importul istoric, o singură dată

Lista pornește goală, așa că o ramură manuală trage comenzile finalizate din trecut și le trimite prin același flux. Am limitat importul la ultimele 540 de zile: comenzile mai vechi nu ajută, fiindcă membrii lor ar expira oricum.

7. Testul cu validateOnly, apoi pornirea

Primul rulaj se face cu validateOnly: true. Google verifică formatul, accesul și termenii, fără să adauge nimic. Un răspuns cu requestId și fără erori înseamnă că ești gata. Abia apoi treci pe false, rulezi importul istoric și activezi workflow-ul pentru comenzile noi.

Ce nu a mers prima dată

Importul istoric a umplut memoria n8n. Prima variantă folosea nodul WooCommerce cu „Return all” și trăgea comenzile întregi, cu toate produsele, notele și metadatele. După 12 minute de descărcat câte 100 de comenzi pe pagină, instanța a rămas fără memorie și execuția a picat. Am refăcut ramura cu un nod HTTP Request pe API-ul REST WooCommerce, care cere doar câmpurile necesare (_fields=id,status,billing,meta_data, unde meta_data aduce doar bifa de consimțământ) și doar comenzile din ultimele 540 de zile. Același import a durat apoi 75 de secunde.

Webhook-ul WooCommerce nu se crea. n8n își anunța adresa publică pe http, iar WooCommerce cere https pentru livrarea webhook-urilor. Soluția a fost variabila de mediu WEBHOOK_URL setată pe adresa https:// a instanței.

Credențialele dispăreau la fiecare actualizare. Am construit și modificat workflow-ul prin API-ul n8n, iar fiecare actualizare a scos credențialele din noduri. Le-am reselectat manual de fiecare dată. Lecția: strângi toate modificările într-o singură actualizare.

Consimțământul și GDPR

Datele pleacă din n8n doar hash-uite, iar n8n e setat să nu păstreze execuțiile reușite, ca să nu rămână date de client în istoric. Hash-ul nu înseamnă însă că nu mai ai obligații. Datele hash-uite sunt tot date cu caracter personal.

Ce trebuie făcut pentru clienții din Spațiul Economic European, Marea Britanie și Elveția:

1. Semnalele de consimțământ. Din martie 2024, Google cere pentru fiecare încărcare două câmpuri, adUserData și adPersonalization. Datele din SEE fără ambele pe „granted” nu se folosesc pentru personalizarea reclamelor. Semnalul trebuie să reflecte consimțământul pe care l-ai colectat cu adevărat, nu o valoare pusă implicit.
2. Politica de confidențialitate. Trebuie să spună că datele clienților, în formă hash-uită, sunt trimise la Google pentru publicitate, și cum se poate opune clientul.
3. Retragerea consimțământului. Cine se opune trebuie scos din listă, prin audienceMembers:remove sau prin înlocuirea listei.

Cum folosești lista în campanii

• Semnal de audiență în Performance Max. Lista de cumpărători îi arată algoritmului cum arată un client real. E un semnal, nu o țintire strictă.
• Obiectivul „clienți noi” în PMax. Cu lista încărcată, Google poate deosebi clienții existenți de cei noi și poate licita mai mult pe clienți noi sau doar pe ei.
• Excluderi. Lista de 30 de zile scoate din campaniile de prospectare oamenii care tocmai au cumpărat.
• Segmente lookalike în Demand Gen. Audiențele similare clasice nu mai există din 2023. În Demand Gen poți porni segmente lookalike de la lista de cumpărători.
• Smart Bidding. Campaniile cu Smart Bidding folosesc automat listele Customer Match din cont. Cu licitare manuală, listele nu se folosesc deloc.

Ca lista să rămână eligibilă, Google cere ca, în fereastra de 540 de zile, cel puțin 100 de membri să fie adăugați sau actualizați. Un flux automat bifează asta singur, la fiecare comandă.

Rezultatul

• Importul istoric: 75 de secunde, după ce prima variantă căzuse la 12 minute.
• Fiecare comandă finalizată intră în listă automat, fără intervenție.
• Rata de potrivire apare în Audience manager după 7-14 zile. O adaug aici când o am măsurată, la fel și efectul în Performance Max după Black Friday, doar dacă avem o comparație curată.

Limitele soluției

• Comenzile anulate sau rambursate după finalizare nu sunt scoase din listă. Ar cere un al doilea flux, cu audienceMembers:remove.
• Rata de potrivire depinde de câți clienți folosesc la checkout același email ca în contul Google. Pentru emailurile de firmă, potrivirea e de obicei mică.
• În Spațiul Economic European, din martie 2024 listele Customer Match nu se mai folosesc pe site-urile și aplicațiile partenere Google, doar pe proprietățile Google (Search, YouTube, Gmail și celelalte).
• Lista nu ajută campaniile până nu trece pragul minim de membri activi. Un magazin mic poate rămâne sub prag luni de zile.
• Nu înlocuiește un tracking de conversii corect. Customer Match spune cine e clientul, nu ce a făcut după click. Pentru partea de măsurare, vezi configurarea conversiilor și a tracking-ului.

Checklist înainte să pornești

• Contul de Google Ads e eligibil pentru Customer Match
• Lista „Cumpărători” creată, cu 540 de zile
• Data Manager API activat, credențiala OAuth cu scope datamanager
• WEBHOOK_URL pe https:// în n8n
• Normalizarea testată pe exemple reale (email Gmail cu puncte, telefon fără prefix)
• Semnalele de consimțământ reflectă consimțământul real
• Politica de confidențialitate actualizată
• Execuțiile reușite nu se salvează în n8n
• Test cu validateOnly: true trecut
• Import istoric limitat la 540 de zile, doar câmpurile necesare

Surse

• Google Ads API: Get started with Customer Match (durata de 540 de zile, normalizare)
• Google Ads API: Feature deprecations (restricția din 1 aprilie 2026 și eroarea CUSTOMER_NOT_ALLOWLISTED_FOR_THIS_FEATURE)
• Data Manager API: Best practices (loturi de până la 10.000 de membri)
• Data Manager API: Format user data (regulile de normalizare și hash)
• Google Ads Help: EU user consent policy for Customer Match upload partners
• Google Ads Help: About Customer Match (rețele, Smart Bidding, pragul de 100 de membri, SEE din martie 2024)
• PPC Land: Google forces Customer Match uploads to Data Manager API by April 1