Parametr Facebooku v URL fbclid a jeho odebrání.

Co se stalo?

Facebook začal přidávat do URL adresy prokliku z Facebook postů  parametr fbclid (Facebook Click Identifier).

Tento parametru se objevuje jen u webové verze Facebooku a to jak na destop tak mobilní verze webu, zatím se neobjevil nikde na Andriod či IOS aplikacích.

K čemu slouží?

Facebook díky tomuto parametrů zjistí, tedy pokud je na dané koncové URL FB pixel, co se dělo na daném koncovém webu v dané okně prohlížeče. Lépe si spojí návštěvy a bude mít ještě více dat.  Pokud by Facebooku zrušili cookie třetí strany, tak takto si vás Facebook označí a spojí.

Pomáhá tento parametr někomu jinému než interní analytice Facebooku?

Co já vím, tak nikomu. S tím jak více škodí než pomahá, byl bych rád kdyby zmizel a třeba i zmizí.

Pohled SEO specialisty

Daný parametr fbclid může být indexován a způsobit problémy s duplicitami. Další probléme je z odkazy, protože se tam rozmnělní jejich kvalita. Při organickém sdílení se může stávat, že uživatelé tento parametr nechají v URL.

Z pohledu SEO tedy může uškodit.

Pohled webového analytika

Rozhodít to analýzu stránek, budete si muset to v reportingu manuálně spojovat a opravovat.

Z pohledu Social media marketéra

Tak nevím o ničem, v čem by daný parametr pomáhal a vědělo by se o tom. Jediné riziko je, že uživatelé budou organicky sdílet tento obsah i s tímto měřicím parametrem a ještě se to bude šířít.

Z pohledu PPCčkaře

Problém s přesnout shodou na dané URL a tedy problém s menším publikem pro remarketing.

Z pohledu UXáka

Problém s přesnout shodou na dané URL, stejně jako u PPC, jen to bude v nástrojích pro snímání heatmap etc. kde v dané vzorku pak nebudou uživatelé z Facebooku. Dále bude rozmělněná cesta uživatele přes web na spousty jednotlivých vstupních stránek místo jedné správné.

Z pohledu uživatele

Nepěkná URL co si nezapomatuje a jen to tam je navíc, spíše ho to bude otravovat. Při sdílení se může stát, že někdo pak nasdílí odkazy i s tímto parametrem a udělá z toho ještě větší problém.

Řešení:

1) Ponechat parametr v URL a opravit to v místech, kde je potřeba.

SEO:

  1. Canonical URL – doporučení na indexovanou URL. Může pomoci ochrání od indexace v SERPu, ale i tak to často zaindexovaná URL s tímto parametrem.
  2. Zákaz v robots.txt – optimalizace crawl budgetu. Říkáte robotů, neplýtej čas na procházení těchto odkazů.
  3. Zakaz indexace v meta robots v headu stránky. – Nejjistěší ochrana před indexací stránky s parametrem. Podmínka je když je v URL změň meta robots na :
  4. Vyloučení parametru v Search console. Zde nastavité, že se jedná o pasivní parametr a nemá vliv na obsah.

Webová analytika:

  1. Upravit analytiku tak, aby do GA a dalších nástroju padala jen ošetřená URL. Za mě je dobré pak si odesílat pravou URL do vlastní dimenze.  Kód je na konci stránky.

Detailní pohled na opravu dat v Google Analytics

Vše co uděláte opraví jen nově změřená data.

Oprava přes vyloučení parametru v Google Analytics

  • Jednoduchá oprava
  • Potřeba práv na edit v daném pohledu na data v Google analytics.
  • Při hooodně profilem nudná repetetivní oprava, není systémová, nutnost v budoucnu na to pamatovat.
Postup:
  1. Jít do Google analytics
  2. Jít do GA> Admin > View setting
  3. Přidat tam do „Exclude URL Query Parameters“ hodnotu „fbclid“
  4. Uložit
  5. Zopakovat na všech view kde to chcete opravit.

 

Skript Google tag manage proměnná pro opravu URL pro Google Analytics

Proč?

Protože máte 100+ Google analytics a do některých nemáte ani přístup a přesto chcete to vyloučit ze všech GA a můžete to řešit jen přes GTM. Kromě toho parametru, chcete z URL vyříznout i další co vám tam jen dělají nepořádek.

Postup:
  1. Zajít do Google tag manageru.
  2. Vytvoři proměnnou.
  3. Otestovat ji.
  4. Zajít do vaší Google analytics setting proměnné, aby jste to nemuseli dávat manuálně do každé značky.
  5. Ve fields použít parametr page a rovná se tato proměnná.
  6. Otestovat
  7. Publikovat.

Rozšíříl jsem tento skript aby fungoval i pro více parametrů a upravil ho pro učely měření Google analytics.

Kromě toto účelu ho používám i pro odříznutí některých parametrů co v analytice prostě nechci nebo je mám raději ve vlastní dimenzi.

Další varianty:

Více parametrů:
removemultipleParams(„fbclid,dalsi_parametr,adalsi,“,window.location.pathname + window.location.search) }

Přidání hashe:

removemultipleParams(„fbclid,“,window.location.pathname + window.location.search) +window.location.hash

Parametry přes proměnnou:

removemultipleParams(„{{tvoje.promenna}},“,window.location.pathname + window.location.search)

Celá URL:

removemultipleParams(„fbclid,“,window.location.href )

 

2) Totální odstranění parametru přímo na serveru.

Nedělejte to, když tomu nerozumíte.

Nenesu odpovědnost za vaše nasazení…

Tohle je obecný návod, který nemůže znát specifika vašeho nastavení serveru.

Výhoda tohoto řešení:

  • Ošetření všeho naráz.
  • Funguje i bez JS.
  • Stejně však doporučím implementovat canonical a robots.txt úpravu.
  • Nejlepší trvalé řešení

Nevýhoda:

  • Potřebujete developera nebo člověka co umí nastavit danou věc na serveru, ale opravdu se to vyplatí 😉 . Pokud budete mít dobrého developera, tak ten to udělá za vás, ani o tom nebudete vědět 😀 .

Oprava přes Htaccess

Oprava přes Htaccess pokud máte wordpress WordPress:

Další pohled je cachování souborů, kdy je ideální nastavit, aby caching ténto parametr ignorovalo.

Pokud si na to netroufáte požádejte o odebrání toho parametru z URL vašeho developera. Požádejte o přesměrování typu 301, které odebere daný parametr z URL a přesměruje zpět na původní URL.

 

 

3) Za mě špatné řešení.

Javascriptové odstranění parametru z URL přesaní URL již načtené stránky.

  • Paramet fbclid jde zaindexovat Googlem i Sezname(no js), očekávajte problémy v SEO.
  • U webu co počítají používají trigger history change (změna url v načteném okně) v analytice se odpálí další pageview > bouncerate 0%. Týká se webů postavených na javascriptu s možností auto trackingu změny URL.
  • Dle polohy replace URL a GA skritpu, tak bude nebo naopak nebude odesílaná pěkná URL, může i záviset na rychlost internetu.
  • Může dělat nepořádek v UX nástrojích, kde bude měřena právě změna URL. Další problém bude s přesnou shodou.

4) Ignorace

  • Rozhodí vám to SEO – Duplicity
  • V analytice budete mít těžkou práci s spojováním dat.
  • Nejhorší nápad, dlouhodobě vás to bude otravovat a krást čas na s každou opravou dat.

Výsledek?

Co jsem udělal na svém blogu?

Chtěl jsem to udělat přes přesměrování na serveru, ale proxy loadbalancer, co je na serveru moji snahu ničí. Takže aktuálně vylučuji na úrovni GA a snažím se to vyřešit. Na dalších webech, kde takovou vymoženost nemám mi to jede 🙂 .

Co jsem dělal u blogu klientu, kde nejsem schopni kontaktovat developera?

Vyloučil jsem parametr v GA a snad to developer podle tohoho návodu tam někdy opraví.

Co dělal složitý klient?

První vyloučení v GTM 😉 a pak to asi i vyloučíme přes rewrite na serveru.

 

Tak alespoň ve zkratce proč dávám tak rozsáhlý návod :D.

 

Máte nápady na rozšíření článku? Nebo jeho úpravy? Napište mi na sociálních sítích.

.