Ad Hijacking: anatomia tecnica della frode affiliate sul brand bidding e metodologie di detection

Anatomia tecnica della redirect chain

Per capire come funziona tecnicamente l’attacco è necessario distinguere i tre URL coinvolti in un annuncio Google Ads e capire perché la struttura attuale rende il vettore così difficile da bloccare a monte.

Display URL, Final URL e Tracking Template

Google Ads separa l’URL mostrato all’utente nell’annuncio (display URL, derivato dal dominio del Final URL) dall’URL effettivamente caricato al click (Final URL), e introduce un livello opzionale di redirect controllato dall’inserzionista (tracking template, parametro {lpurl}). La policy obbliga il display URL a coincidere con il dominio del Final URL, ma il tracking template può puntare a un dominio terzo che esegue uno o più hop di redirect prima di consegnare l’utente al Final URL. Questa è la fessura strutturale che l’hijacker sfrutta.

Lo schema reale di una catena hijacker, semplificato:

Click utente
  ↓
[1] tracking-affiliate.com/r?id=AFF123&dest=...   (302)
  ↓
[2] cdn-redirect.affiliate-network.com/click/...     (302, set cookie affiliate)
  ↓
[3] go.brandname.com/?utm_source=affiliate&sub=AFF123 (302, dominio "brand-like")
  ↓
[4] www.brandname.com/                               (200, sito reale)

L’utente percepisce solo il display URL (brandname.com) e il caricamento finale del sito legittimo. I quattro hop intermedi avvengono in millisecondi, non sono distinguibili dal punto di vista UX e impostano il cookie affiliate al passaggio 2. Da quel momento, qualsiasi conversione sul dominio brand entro la durata del cookie viene attribuita all’hijacker dal network affiliate.

Cloaking server-side: come gli hijacker eludono i controlli

Gli hijacker più strutturati non eseguono la frode a tappeto. Servono creatività e redirect chain differenti in funzione del visitatore, decidendo lato server se mostrare la versione hijacker o una versione compliant pulita. I segnali di filtro più comuni:

• Geolocalizzazione IP: la versione hijacker viene servita solo agli IP residenziali del paese target. IP da datacenter o ASN noti per essere associati a tool di brand protection ricevono la versione pulita.
• User-Agent fingerprinting: oltre al match esatto sulla stringa UA, vengono incrociati Accept-Language, Accept-Encoding, ordine degli header HTTP/2, supporto per JA3/JA4 fingerprint TLS. Una richiesta con UA Chrome ma fingerprint Python è immediatamente declassata.
• Behavioral signals: tempo di permanenza sulla pagina di redirect, presenza di cookie pregressi, profilo del referer. Una sessione “fredda” (no cookie, no history, navigazione lineare e veloce) viene flaggata come bot.
• Frequency capping per IP: lo stesso IP che richiede l’annuncio più di N volte in T secondi viene silenziato e riceve la versione pulita. I tool di brand protection a scansione massiva rientrano facilmente in questa soglia.
• Time-of-day bidding: la campagna hijacker è attiva solo nelle fasce orarie ad alto traffico organico brand (peak hour del paese target), per massimizzare la sovrapposizione con utenti realmente intenzionati.

L’effetto netto è che il monitoraggio “ingenuo” — uno script che interroga la SERP da un server cloud ogni N minuti — ha un tasso di rilevamento prossimo a zero contro hijacker professionali. L’unico approccio efficace è la scansione da IP residenziali, con browser reali, in finestre temporali e geo-mix che replicano il comportamento dell’utente medio del brand.

Trace della redirect chain con curl

Il primo strumento per dissezionare un sospetto hijacker, una volta identificato l’URL del tracking template (visibile dall’inspection del link sponsorizzato), è una richiesta HTTP a basso livello che segua i redirect senza eseguire JavaScript. Spoof completo dello User-Agent e degli header che un browser invierebbe:

curl -sIL \
  -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/132.0.0.0 Safari/537.36" \
  -H "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" \
  -H "Accept-Language: it-IT,it;q=0.9,en-US;q=0.8,en;q=0.7" \
  -H "Accept-Encoding: gzip, deflate, br" \
  -H "Sec-Fetch-Dest: document" \
  -H "Sec-Fetch-Mode: navigate" \
  -H "Sec-Fetch-Site: cross-site" \
  -H "Sec-Fetch-User: ?1" \
  -H "Upgrade-Insecure-Requests: 1" \
  --resolve "tracking-affiliate.com:443:<IP_RESIDENZIALE>" \
  "https://tracking-affiliate.com/r?id=AFF123&dest=https%3A%2F%2Fwww.brandname.com" \
  | grep -iE "^(HTTP|Location|Set-Cookie):"

L’output mostra ogni hop con status code, Location di destinazione e cookie impostati lungo la catena. Tre indicatori da cercare: domini intermedi non riconducibili al programma affiliate ufficiale, cookie impostati da terze parti con TTL elevati (30-90 giorni), discrepanza tra il dominio del Final URL e il dominio dichiarato nel display URL. Per superare il cloaking IP è necessario originare la richiesta da un IP residenziale del paese target — o, in alternativa, ripetere il trace da un browser reale via Playwright.

Economia della frode e impatto sul brand

L’impatto dell’ad hijacking è triplo e si manifesta su tre voci di costo non sempre attribuite alla loro causa reale.

CPC inflation nell’auction Google Ads

L’auction di Google Ads sulle keyword brand è normalmente poco competitiva: l’inserzionista titolare del trademark beneficia di Quality Score elevato (CTR atteso alto, landing page rilevante, ad copy con match esatto col brand) e di un Ad Rank dominante a costi-per-clic minimi. L’ingresso di un hijacker — che non ha gli stessi vincoli di Quality Score perché ha keyword broad/phrase su brand altrui ma compensa con bid aggressivi — modifica l’equilibrio. L’auction obbliga il titolare ad alzare il bid per mantenere la posizione 1 sui propri trademark, con incremento del CPC medio anche del 30-80% in funzione dell’aggressività dell’hijacker. Su keyword brand ad alto volume questo si traduce in migliaia di euro al mese di costo aggiuntivo, attribuiti dal team marketing a una generica “competizione in aumento” piuttosto che alla causa reale.

Attribution hijacking sulle conversioni

Il danno strutturalmente più grave è invisibile ai dashboard Google Ads. La maggior parte dei programmi affiliate adotta modelli di attribuzione last-click con cookie window di 30-90 giorni. Quando l’utente transita per la redirect chain hijacker, il cookie affiliate impostato sopravvive a tutte le sessioni successive del periodo: ogni acquisto che l’utente farà nei mesi successivi sul dominio brand, anche dopo essere arrivato per via diretta, organica o tramite la newsletter ufficiale, verrà attribuito all’hijacker dal network e generata una commissione di payout. Il brand paga due volte: il CPC inflated all’inizio del journey e la commissione affiliate alla conversione, per un utente che era già suo.

Stima del danno: simulazione su brand con 1M€/anno spend

Per dare ordine di grandezza, considerando un advertiser e-commerce italiano con 1.000.000€ di spend search annuo di cui il 35% concentrato su keyword brand (proporzione tipica per brand maturi):

• Spend brand: 350.000 €/anno
• CPC inflation media in presenza di un hijacker attivo: +40%, equivalente a 100.000 €/anno di costo aggiuntivo non strategico
• Volume di sessioni intercettate: 8-15% del traffico brand, in funzione della copertura geo e oraria dell’hijacker
• Commissioni affiliate indebite: assumendo conversion rate del 4% sul traffico brand e commissione del 6%, su un giro affari brand di 5M€ corrispondono a 24.000-45.000 €/anno di payout fraudolenti
• Totale danno annuo stimato: 124.000-145.000 €, ovvero il 12-15% dello spend search totale

La stima è prudenziale e non considera l’effetto compounding di hijacker multipli che si attivano serialmente sullo stesso brand, scenario tipico nei verticali fashion, beauty e travel.

Detection: metodologia investigativa multi-segnale

Nessun singolo segnale è sufficiente a confermare un caso di ad hijacking. La detection robusta incrocia almeno tre fonti dati indipendenti — Google Ads, Google Search Console e affiliate platform — più un livello di SERP monitoring attivo eseguito da browser reali geo-distribuiti. Il ruolo di ciascuna fonte è asimmetrico: i segnali Ads e GSC sono indicatori della presenza di un problema, gli affiliate dashboard e il SERP monitoring sono evidenze per identificare l’attore.

Segnali da Google Ads

Sulle campagne brand, i pattern indicativi sono:

• Search Lost Impression Share (Rank) sopra il 5% su keyword brand exact match — dovrebbe essere prossimo a zero in assenza di concorrenza significativa
• Top Impression Share assoluto in calo a parità di bid e budget — segnale che qualcuno sta entrando in auction sopra di noi su trademark proprietari
• Auction Insights: comparsa di domini sconosciuti, varianti tipografiche del brand o domini affiliate-network con overlap rate stabile sopra il 15% sulle campagne brand
• CPC medio in crescita progressiva sulle stesse keyword brand a parità di Quality Score — lo stesso QS in ambiente più competitivo costa di più

L’analisi va condotta a livello di singola keyword e singola location, perché gli hijacker sono spesso geo-mirati e un’aggregazione nazionale dilava il segnale.

Segnali da Google Search Console

GSC fornisce un controfattuale prezioso. Quando un hijacker intercetta traffico paid brand, l’effetto collaterale è un calo del CTR organico sulle stesse query a parità di posizione media: l’utente che vede l’annuncio (presunto del brand) lo clicca anziché scendere al risultato organico. Il pattern da cercare nei dati GSC, filtrando le query brand exact:

• CTR organico in calo a parità di posizione media stabile (tipicamente 1.0-1.5 per query brand)
• Impression organiche in crescita mentre i click ristagnano — il volume di ricerca cresce ma una porzione viene catturata sopra-la-piega
• Differenziale day-of-week: nei giorni in cui l’hijacker è inattivo (es. weekend, se opera B2B) il CTR torna ai livelli storici

L’estrazione via GSC API permette di costruire una serie storica giornaliera CTR per query brand e applicare un controllo di stazionarietà. Una rottura del trend su più query brand contemporaneamente, non spiegata da feature SERP nuove (sitelink, knowledge panel), è un indicatore forte.

Segnali da affiliate platform

I dashboard dei network affiliate (Awin, TradeDoubler, Impact, ShareASale, CJ Affiliate) consentono il segmento di analisi più diretto. Pattern da identificare:

• Affiliate ID con conversion rate fuori scala — tipicamente 3-5x rispetto alla media del programma. L’hijacker intercetta utenti già a fondo del funnel, quindi converte come se fosse un canale di retargeting
• Time-to-conversion sotto 5 minuti sulla maggioranza degli ordini — coerente con utenti che stavano già acquistando
• Pattern di traffico solo durante orari peak e assenza nei picchi di campagne paid brand stoppate (test diagnostico)
• Referrer mancante o anonimizzato nei dettagli del click, oppure referrer che riporta a domini affiliate-redirect generici

Un test diagnostico definitivo: spegnere per 24-48 ore le campagne brand su Google Ads in un mercato e osservare il volume di conversioni dell’affiliate sospetto. Se il suo traffico crolla in proporzione al traffico paid brand spento, l’evidenza di hijacking è solida. Va eseguito in finestra controllata e con stakeholder allineati, perché comporta un calo temporaneo di vendite.

Pipeline di SERP monitoring con Playwright

Il monitoraggio attivo della SERP brand è la fonte di evidenze più diretta, ma richiede un setup non banale per superare il cloaking. L’approccio efficace usa Playwright in modalità headed (browser visibile, non headless), con UA realistico, pool di proxy residenziali geo-distribuiti e rotation delle finestre temporali. Lo script seguente esegue una query brand, intercetta gli annunci sponsorizzati, ricostruisce la redirect chain di ciascuno e produce un report strutturato.

"""
Brand SERP monitoring per detection ad hijacking.
Requisiti: playwright, tldextract. Esecuzione: python brand_monitor.py
Note: i selettori SERP di Google cambiano frequentemente. Verificare e aggiornare
ad ogni esecuzione. Eseguire da IP residenziale (proxy) per evitare cloaking.
"""
import asyncio
import json
from datetime import datetime, timezone
from urllib.parse import urlparse
import tldextract
from playwright.async_api import async_playwright

BRAND_DOMAIN = "brandname.com"
QUERIES = ["brandname", "brandname offerte", "brandname login"]
LOCALE = "it-IT"
PROXY = {"server": "http://<proxy_residenziale>:<port>",
         "username": "<user>", "password": "<pass>"}

UA = ("Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 "
      "(KHTML, like Gecko) Chrome/132.0.0.0 Safari/537.36")


def is_brand_domain(url: str) -> bool:
    ext = tldextract.extract(url)
    return f"{ext.domain}.{ext.suffix}" == BRAND_DOMAIN


async def trace_redirects(context, ad_url: str) -> list:
    """Apre l'URL dell'annuncio in una nuova pagina e registra ogni navigazione."""
    chain = []
    page = await context.new_page()

    def on_request(request):
        if request.is_navigation_request():
            chain.append({
                "url": request.url,
                "method": request.method,
                "ts": datetime.now(timezone.utc).isoformat(),
            })

    page.on("request", on_request)
    try:
        await page.goto(ad_url, wait_until="domcontentloaded", timeout=20000)
        await page.wait_for_timeout(3000)
        chain.append({"url": page.url, "final": True,
                      "ts": datetime.now(timezone.utc).isoformat()})
    except Exception as e:
        chain.append({"error": str(e)})
    finally:
        await page.close()
    return chain


async def scan_query(context, query: str) -> dict:
    page = await context.new_page()
    await page.goto(f"https://www.google.com/search?q={query}&hl=it&gl=it",
                    wait_until="networkidle")

    # Selettore: contenitori annunci con attributo data-text-ad.
    # AGGIORNARE quando Google cambia il DOM (verifica trimestrale).
    ads = await page.query_selector_all('div[data-text-ad="1"], div[data-text-ad]')
    results = []
    for ad in ads:
        link_el = await ad.query_selector("a[data-pcu], a[href]")
        if not link_el:
            continue
        href = await link_el.get_attribute("href")
        display = await link_el.get_attribute("data-pcu") or ""
        if not href:
            continue
        chain = await trace_redirects(context, href)
        final_url = next((h["url"] for h in reversed(chain) if h.get("final")),
                         None)
        results.append({
            "ad_href": href,
            "display_url": display,
            "redirect_chain": chain,
            "final_url": final_url,
            "lands_on_brand": is_brand_domain(final_url) if final_url else False,
            "hops": len([h for h in chain if "url" in h]),
            "intermediate_domains": [
                tldextract.extract(h["url"]).registered_domain
                for h in chain if "url" in h
                and not is_brand_domain(h["url"])
            ],
        })

    await page.close()
    return {"query": query, "ads_found": len(results), "ads": results}


async def main():
    async with async_playwright() as p:
        browser = await p.chromium.launch(headless=False, proxy=PROXY)
        context = await browser.new_context(
            user_agent=UA, locale=LOCALE,
            viewport={"width": 1920, "height": 1080},
            timezone_id="Europe/Rome",
        )
        report = {"timestamp": datetime.now(timezone.utc).isoformat(),
                  "brand": BRAND_DOMAIN, "queries": []}
        for q in QUERIES:
            report["queries"].append(await scan_query(context, q))
            await asyncio.sleep(20)  # rate limiting umano
        await browser.close()

    with open(f"brand_serp_{datetime.now().strftime('%Y%m%d_%H%M')}.json",
              "w", encoding="utf-8") as f:
        json.dump(report, f, indent=2, ensure_ascii=False)


if __name__ == "__main__":
    asyncio.run(main())

Il report JSON in output abilita una pipeline di alerting: qualsiasi annuncio con lands_on_brand=true ma hops > 1 e intermediate_domains popolato è un candidato hijacker da verificare. Lo stesso script va schedulato a intervalli randomizzati (non a orari tondi, che vengono filtrati dai sistemi di cloaking) e da pool di proxy residenziali con rotation per CAP/regione, replicando la distribuzione demografica del traffico brand.

Nota sui selettori SERP: Google modifica periodicamente la struttura DOM dei risultati a pagamento. I selettori basati su data-text-ad reggono da anni ma vanno verificati prima di ogni release del monitor. Mantenere una suite di test che fallisce esplicitamente quando il numero di annunci rilevati scende sotto la soglia attesa è essenziale per evitare falsi negativi silenti.

Stack tool di brand protection PPC

Per advertiser con spend search significativo, il monitoraggio interno con Playwright è la prima linea di difesa ma raramente è sufficiente da solo. La copertura geo capillare, la rotation di IP residenziali su scala globale, l’integrazione con i workflow di reclamo verso Google e i network affiliate richiedono infrastruttura che non vale la pena costruire in-house oltre una certa soglia. I principali vendor enterprise sul mercato, valutati su criteri tecnici:

I primi tre sono i player storici dello “search brand protection” puro. ClickGUARD si posiziona principalmente sul click fraud generico (bot, click farm) ma copre anche il brand bidding non autorizzato. AppsFlyer Protect360 è specializzato nel mobile install fraud e diventa rilevante quando l’hijacking si estende alle campagne app-install di Google Ads e Apple Search Ads. La scelta dipende dal vertical (e-commerce vs lead-gen vs app), dal mix di mercati e dalla maturità del programma affiliate. Tutti e cinque richiedono setup tecnico non banale e contratti annuali a fascia enterprise.

Difesa: stack di protezione end-to-end

La detection è solo metà del lavoro. Senza una pipeline di response strutturata su più livelli — contrattuale, tecnico, policy, legale — l’hijacker individuato torna attivo nel giro di settimane sotto un altro account. La difesa efficace integra cinque livelli.

Livello contrattuale: clausole tecniche per programmi affiliate

I termini di servizio dei programmi affiliate sono spesso generici sul tema brand bidding (“you may not bid on our trademarks”). Una clausola difendibile in giudizio e operativamente azionabile deve includere:

• Lista esplicita dei trademark protetti, inclusi misspelling e varianti tipografiche
• Divieto esplicito di display URL coincidente o simile al dominio brand, indipendentemente dal final URL
• Divieto di redirect intermedi non dichiarati nella destination URL chain
• Obbligo di whitelist degli ASN/IP da cui l’affiliate fa monitoring delle proprie campagne, per consentire al brand di richiedere log e verificare cloaking
• Penali quantificate in caso di violazione (forfeiture delle commissioni del periodo + clawback retroattivo)
• Diritto del brand di sospendere unilateralmente l’account in caso di evidenza tecnica di hijacking, senza preavviso

Livello Google Ads: configurazione difensiva

Il bidding difensivo sul proprio brand non è opzionale, è strutturale. Va configurato puntando esclusivamente alla prima posizione assoluta (Top IS >= 95%) con keyword exact match e match phrase aggressive sui trademark, ad copy con sitelink completo e final URL ben mappato. Approfondimento operativo nella guida dedicata alla corrispondenza delle parole chiave in Google Ads e nelle metriche da monitorare descritte nell’analisi della quota impressioni.

Configurazioni aggiuntive consigliate:

• IP exclusions: applicare gli IP noti di network affiliate sospetti come esclusione a livello account
• Audience signals: aggiungere come signal positivo l’audience “visitatori del sito ultimi 90 giorni” sulle campagne brand, per mantenere prominenza anche con bid contenuti
• Google Ads Scripts: schedulare uno script che monitori l’Auction Insights ogni 6 ore e generi alert email su nuovi competitor con overlap rate sopra soglia
• Tracking template lockdown: usare ValueTrack parameters fissi ({lpurl}?utm_source=google&utm_medium=cpc) e verificare via API che nessun tracking template di terze parti sia stato iniettato a livello di gruppo annunci o annuncio

Livello policy: il reclamo Trademark a Google

Google offre due strumenti di policy distinti che vengono spesso confusi. Il primo è la Trademark Authorization, che limita l’uso del marchio nel testo dell’annuncio: utile contro competitor che inseriscono il brand nel copy, inutile contro hijacker che usano solo il brand come keyword. Il secondo è la Trademark Complaint per uso non autorizzato del marchio, da inviare via il form ufficiale Google Ads Trademark Policy. Per essere accettato, il reclamo deve includere:

• Numero di registrazione del trademark e jurisdiction
• Lista delle keyword brand specifiche
• Screenshot dell’annuncio infringente con timestamp e geolocalizzazione
• Catena URL completa (output del trace) che mostra il redirect
• Identificazione precisa del Customer ID dell’inserzionista, se nota

Il tempo di processing tipico è di 5-10 giorni lavorativi. Reclami parziali o senza evidenza tecnica vengono respinti con messaggio generico che non specifica la causa, motivo per cui un dossier ben strutturato fin dal primo invio fa la differenza tra una sospensione rapida e settimane di ping-pong.

Livello cross-engine: oltre Google

L’hijacking non è esclusivo di Google Ads. Microsoft Advertising ha quote di mercato in crescita anche grazie all’integrazione con Copilot, e ha una propria Trademark Policy con processo di reclamo separato. Bing è storicamente più permissivo sul brand bidding e gli hijacker che vengono espulsi da Google si riposizionano su Microsoft Ads nel giro di giorni. Anche TikTok Ads, Reddit Ads e i network programmatici legati a piattaforme social vanno monitorati, in particolare per i brand con audience giovane. Il monitoraggio cross-engine va incluso nello scope dei tool di brand protection enterprise scelti.

Livello legale: DMCA, cease & desist e azioni in tribunale

Quando l’hijacker è strutturato e ricorre nonostante le sospensioni, l’escalation legale diventa inevitabile. La giurisdizione è complessa perché l’hijacker spesso opera da paesi diversi da quello del brand, ma le leve disponibili includono:

• Cease & desist diretto, accompagnato dal dossier tecnico, con indicazione delle penali contrattuali maturate
• DMCA takedown notice verso l’hosting provider del dominio di redirect (generalmente accolto rapidamente per uso non autorizzato di trademark)
• UDRP (Uniform Domain-Name Dispute-Resolution Policy) se l’hijacker utilizza un dominio che incorpora il trademark del brand
• Azioni civili sotto Lanham Act (US), EU Trade Mark Regulation (UE) o legislazioni nazionali di unfair competition, con richiesta di danni e ingiunzione

Nuove superfici di hijacking nel 2026

L’evoluzione del search ecosystem ha aperto nel biennio 2024-2026 nuovi vettori di hijacking che non rientrano nei pattern tradizionali e su cui i tool di brand protection storici sono ancora in rincorsa.

Performance Max: l’opacità che protegge gli hijacker

Performance Max non espone agli inserzionisti la granularità necessaria per identificare l’hijacking interno alle proprie campagne. La rotation degli asset, la scarsa visibilità sulle query effettivamente servite, l’aggregazione dei dati di placement rendono difficile capire se un asset combinato sta servendo creatività hijacker su keyword brand. La contromisura operativa è duplice: tenere le campagne brand fuori da Performance Max usando esclusioni di brand list specifiche, e analizzare via API i Search Term Insights con frequenza settimanale, applicando alerting su query brand che generano spend significativo dentro PMax invece che dentro le campagne brand dedicate.

AI Overviews e citation hijacking

Le AI Overviews di Google, integrando link sponsorizzati nelle risposte generative, hanno introdotto una superficie di hijacking nuova: l’inserzionista citato dall’AI Overview come “fonte” può non essere il brand legittimo ma un affiliate che fa bid su keyword informazionali correlate al brand. L’effetto è amplificato perché l’AI Overview genera trust automatico (“Google ha selezionato questa fonte”) e l’utente clicca sull’affiliate convinto di consultare un contenuto autorevole. Il monitoraggio richiede scraping delle AI Overviews oltre alla SERP standard e l’inclusione delle query informazionali brand-related (es. recensioni brandname, brandname vs competitor) nel set monitorato.

Demand Gen e Shopping ads

Demand Gen porta il problema sui placement YouTube, Discover e Gmail. Shopping ads, in particolare le Free Listings e i Performance Max Shopping, sono vulnerabili a sellers di terze parti che listano prodotti con titolo e immagine del brand ma redirigono a marketplace o store concorrenti. Il monitoraggio richiede integrazione con Google Merchant Center e scraping delle Shopping SERP da geo-mix realistico, scope che pochi tool generalisti coprono adeguatamente.

Checklist operativa di brand protection PPC

Sintesi delle azioni minime per un advertiser con programma affiliate attivo e spend search rilevante. La sequenza è ordinata per priorità implementativa: i primi punti vanno chiusi prima di passare ai successivi.

1. Registrare formalmente i trademark nelle giurisdizioni rilevanti e attivare la Trademark Policy di Google Ads e Microsoft Advertising.
2. Aggiornare i T&C del programma affiliate con clausole tecniche dettagliate su brand bidding, display URL e redirect chain (vedi sezione contrattuale).
3. Configurare campagne brand difensive con Top Impression Share >= 95% e tracking template lockdown.
4. Implementare la pipeline Playwright di SERP monitoring da pool di proxy residenziali con rotation geo e oraria.
5. Costruire una dashboard che incrocia Search Lost IS Rank, Auction Insights, CTR organico GSC sulle query brand e conversion rate per affiliate ID.
6. Definire una policy di response con SLA per ogni livello di evidenza: avviso interno (24h), reclamo Google (48h), cease & desist (7 giorni), escalation legale (30 giorni).
7. Eseguire un test diagnostico trimestrale di sospensione campagne brand in un mercato secondario e analisi del traffico residuo per affiliate.
8. Estendere il monitoraggio a Performance Max (Search Term Insights settimanali), AI Overviews (scraping query informazionali) e Shopping ads (Merchant Center cross-check).
9. Per spend search sopra 500.000 €/anno, valutare l’adozione di un tool enterprise di brand protection con copertura cross-engine e workflow di reclamo integrato.
10. Rivalutare quarterly il setup completo: i pattern degli hijacker evolvono e le contromisure di sei mesi fa diventano rapidamente obsolete.

Il tema si interseca con la riallocazione del budget Google Ads (parte del CPC inflation va riassorbita ribilanciando lo spend), con la sinergia SEO vs PPC sulle query brand (un brand con presenza organica dominante riduce la finestra economica per l’hijacker) e con i pattern difensivi descritti nelle tecniche di attacco e difesa dalla Negative SEO, che condividono la logica di monitoraggio investigativo applicata invece al canale organico.

Domande frequenti

Bidare sul proprio brand è davvero necessario?

Sì, se esiste un programma affiliate aperto o competizione attiva sui trademark. Il costo del bid difensivo è quasi sempre inferiore al danno combinato di CPC inflation e attribution hijacking che si verifica lasciando l’auction sguarnita. Il calcolo va fatto a livello di singolo mercato e va rivalutato quando il programma affiliate cambia struttura.

Google sospende sempre l’inserzionista che fa hijacking?

No. Google sospende l’inserzionista solo se il reclamo è corredato da evidenza tecnica solida e di sua competenza policy (uso non autorizzato di trademark, display URL non coerente con final URL). Le violazioni puramente contrattuali tra brand e affiliate non sono materia di Google e vanno gestite direttamente con il network affiliate o per via legale.

Quanto costa un tool di brand protection enterprise?

I contratti tipici per i player citati partono da 30.000-50.000 €/anno per copertura monomercato e salgono significativamente per copertura multi-paese e moduli avanzati (cross-engine, mobile app, AI Overviews). Per advertiser con spend search inferiore a 500.000 €/anno, una pipeline interna basata su Playwright e proxy residenziali commerciali raggiunge il 70-80% della copertura a una frazione del costo, ma richiede manutenzione continuativa.

Cosa fare nelle prime 24 ore dalla scoperta di un hijacker?

Nell’ordine: catturare evidenze tecniche complete (screenshot annuncio con timestamp, trace della redirect chain da IP residenziale, log conversioni dell’affiliate sospetto dal network), sospendere temporaneamente l’affiliate ID nel proprio programma, inviare il reclamo Trademark Policy a Google con il dossier completo, allertare il legal interno per valutare cease & desist. La velocità nelle prime 24 ore conta perché gli hijacker professionali ruotano account rapidamente alla prima sospensione.

L’ad hijacking può colpire piccole imprese o solo brand grandi?

Colpisce qualsiasi brand abbia volume di ricerca brand misurabile e un programma affiliate aperto. La soglia minima di interesse per un hijacker professionale è nell’ordine di 5.000-10.000 ricerche mensili sul nome di marca, con spread sufficiente tra CPC e commissione affiliate. Brand B2B con volumi più bassi sono raramente target, ma e-commerce verticali in fashion, beauty, viaggi, supplements e gambling sono colpiti anche con volumi modesti.

Autore

Giovanni Sacheli Consulente in Search Marketing @Eve Milano

Mi chiamo Giovanni Sacheli e dal 2009 aiuto le aziende a farsi trovare online. Sono specializzato in SEO tecnica e PPC, competenze che applico quotidianamente nella mia agenzia, Searcus Swiss Sagl. Mi piace sviluppare strumenti a supporto del mio lavoro, ho creato SEOdata.app e cluster.army e co-scritto il libro SEO Audit Avanzato. Curo maniacalmente questo blog per colleghi e appassionati, dove mi "appunto" quello che imparo. Sono un NERD anni '80, motociclista e orgoglioso papà di due bambini.

Link:
Giovanni Sacheli
SEO Audit Avanzato
Searcus Swiss Sagl
SEOdata.app
cluster.army