Kategoriarkiv: Fakta

Annonsblockering hotar dina inkomster

För ett tag sedan var jag på besök hos Google i London för att samtala om deras annonslösning Adsense. Det kom då på tal om hur tillägg till webbläsare i form av annonsblockering används av alltfler personer, någon siffra ville dock inte Google dela med sig utav.

Jag har under knappt 2 veckor samlat in data på en av mina mest välbesökta sidor, en sida som har en jämn demografi. 13% av besökarna från datorer blockerar annonserna medan motsvarande siffra för mobiler+surfplattor är 0,15%. Har du stor andel trafik via mobiler kan du således skatta dig lycklig just till detta bekymmer även om det uppstår andra saker på dessa enheter, något den aktuella sidan har med sina 47%.

Andel med annonsblockering
Andel besökare som använder annonsblockering. Data: missatsamtal.se

Det är således ett relativt vanligt problem med att folk, inklusive mig själv, blockerar annonser på webbsidor. Effekten varierar såklart beroende på vilken målgrupp samt geografi din sida riktar sig mot, data ovan vill jag nog påstå är normalt för generella sidor i Sverige.

Hur mäter jag detta?

Eftersom blockering sker i klienten, är det där du får lägga in logiken. Ett enkelt sätt är att inkludera en javascript-fil som har ett ”annonslikt” namn där du ändrar värdet på en variabel. Tilläggen som blockerar annonser kommer inte läsa in javascript-filen och variabeln blir oförändrad.

Om du använder Google Analytics kan du enkelt skapa en händelse för alla som blockerar dina annonser och sedan via segment filtrera och analysera all data.

Kodexempel:

<script>
var aCheck = true;
</script>
<script src="/advertisement.js"></script>
<script>
if(aCheck) {_gaq.push(["_trackEvent","Test","Blocker"]);}
</script>

Med samma logik kan du även utföra andra saker såsom att visa ett meddelande, skapa upp andra text-annonser eller bara dölja eventuellt tomt utrymme.

Vore intressant att se vad ni andra har för erfarenheter och statistik på era webbplatser.

Varför försvinner sökorden?

Med tanke på den dramatiska ökningen av andelen (not provided) i Google Analytics och kringliggande diskussioner tänkte jag dra en mer teknisk aspekt om varför detta uppstår. Har tidigare skrivit ett inlägg om (not provided) men här kommer ännu ett.

https
Google när den besöks krypterat via tls

När man besöker en webbsida görs vanligen all överföring av data mellan server och webbläsare via http. På sidor som har ssl/tls kan denna trafik dock transporteras krypterat i protokollet https vilket är just det Google på senare tid allt oftare använder.

(not provided) visas i Google Analytics då man inte kan avläsa vad användaren sökte på, detta då data saknas i ett fält som heter http referer. Så varför saknas denna data allt oftare, är gänget på Google Analytics så elaka att de manuellt plockar bort denna information och ersätter med (not provided)? Troligen inte, det är en direkt följd av tekniska begränsningar i ssl/tls samt ett val som teamet som driver söktjänsten gjort.

Problem HTTPS

Om man kommer från en sida som har https och landar på en sida som kör okrypterat, d.v.s. http, då skickas ingen http referer med oavsett hur gärna du vill, detta då reglerna för hur https fungerar är sådana. Varken Google Analytics eller någon annan leverantör av statistik kan visa sökorden för besökare som går från krypterad till okrypterad sida.

Problem inloggad användare

Om en användare är inloggad på Google väljer Google aktivt att blocka bort information från http referer, de visar endast att du kom från t.ex. google.se, men inga sökord eller annan information skickas med. Precis som i fallet ovan är både gänget på Analytics såsom alla andra leverantörer helt körda att visa några sökord.

Lösning problem HTTPS

Om du har en krypterad sida, antingen med ssl eller tls skickas http referer och både Google Analytics och övriga leverantörer kan visa vad användaren sökte på. Du får helt enkelt kryptera din sida så får du data precis som vanligt.

Lösning problem inloggad användare

Det finns ingen lösning, du är körd oavsett verktyg, detta eftersom Google plockar bort all data förutom domänen besökaren kom från.

Google+ integreras än mer med sök och övriga webb

Idag lanserades två nya uppdateringar till Google+, det handlar om författarskap och inbäddning av material från Google+.

Författarskap

För ungefär 1 år sedan lanserade Google Search , plus your world och började då visa upp innehåll som var länkat till en författare, t.ex. mig. Idag rullade du en relativt stor förändring där deras Google+ inloggning som webbplatser kan använda direkt börjar integreras med författarskap. Just nu fungerar detta bara på ett utvalt antal tjänster såsom WordPress och Typepad, men loggar du in till dessa kopplas dina inlägg automatiskt ihop med författarskap och förknippas med din profil på Google+.

Inbäddat material

Du kan nu bädda in publika inlägg och grupper från Google+ direkt på din webbsida, väldigt likt Twitter, skillnaden är än mer interaktivitet i inläggen. Genom att snabbt kunna dela andras material även utanför deras plattform finns möjlighet att nå än fler personer och de som har Google+ kan snabbt följa författaren och +1:a innehållet. För utvecklare är det bara hugga in och skapa plugin till alla tänkbara plattformar.

 

Blir SEO mer social?

Personligen tror jag sociala medier påverkar, om inte direkt så absolut indirekt genom länkar och att åtminstone ens cirklar ser material och sidor tydligare som man interagerat med.

Senaste analysen jag läste, som härrörde från Custora,  påpekade dock om att social medier stod för en extrem bråkdel av allt förvärv av kunder på alla sidor de hade analyserat. Värt att notera är dock att de exkluderat all trafik som inte innehöll kampanj-taggen. Så alla vanliga besökare som gillar, delar och postar länkar utan att klistra på denna parameter exkluderas helt från statistiken. Likaså togs all direkt trafik bort, så vad analysen visar är helt enkelt fördelningen på de medier som de valt att spåra. Alltså inte hela sanningen.

Ingen vet dock med säkerhet när och hur sökmotorer tar hänsyn till dessa nya signaler i sin ranking, men att använda sociala medier gör man förhoppningsvis av helt andra saker än att boosta sin ranking. Och det här med att sociala signaler är enkel att manipulera och därför inte bör vara en signal, hur svårt är det att skapa en egen länk?

Påverkar sociala signaler din ranking?

Det har på senaste tiden blossat upp allt mer frågor kring sociala medier och om saker där påverkar en webbsidas ranking? Som i de flesta fall där inga definitiva uttalanden finns, senaste jag läst om är på Hacker News, fast även det kan lämna folk till att tolka hans egentliga uttalande.

Vad är då enklast att undersöka om sociala signaler ger någon effekt? Vi kör ett skarpt test på en helt ny sida.

Sociala signaler
Testet använde känd domän fast ny sida

Igår, 5:e September vid 8.30 på morgonen la jag upp min nya sida (missatsamtal.se/sociala-signaler/) på en känd domän som jag ägt i flera år.  Jag plockade bort alla saker som pekade till andra domäner såsom javascript-bibliotek, facebook/Twitter-plugin så de inte blev en eventuell bidragande faktor i testet.

På min profil på Google+ aktiverade jag så mina +1 skulle bli synliga, sedan plussade jag egoistiskt min egen testsida. Den klarsynte ser dock att rubriken på testsidan inte stämmer med min +1, det beror på att jag råkade glömma att ändra rubrik innan jag gjorde +1 och ändrade detta i efterhand på min testsida, något som inte ska påverka resultatet.

Idag, knappt 1 dygn senare finns testsidan på Google, det enda jag gjort var att +1:a testsidan, inga manuellt skapade länkar, inte ens pushat ut sidan i andra sociala medier.

Testet är härmed avslutat och folk får dra sina egna slutsatser huruvida +1 påverkar ranking av webbsidor. Kanske bara den fixar indexering av sidor men värdet av min +1 är noll? Vem vet med säkerhet förutom Matt Cutts & CO.

Uppdatering 2013-09-06 kl 18.30

Sidan rankar nu plats 13 av 593 000 resultat när man söker ”sociala signaler” hos Google och får mer än väl anses ha gett någon inverkan på ranking enligt min bedömning. Ingen annan länk finns till sidan än den som skapades via +1, om denna social signal endast skulle få sidan indexerad borde Google ej placerat den föra 592 987 andra sökträffar. Möjligen spelar domänen in då den inte är helt färsk.
Har nu även redigerat länken som Google+ skapade så den har rätt länknamn, dvs sidans titel. Jag har dock svårt att tro Google skulle ranka sidan lägre om länken innehöll ”sociala signaler” än utan denna fras.

Sidan rankar #13

Tar mer än gärna emot era tankar, är ni fortfarande bergsäkra på att sociala signaler inte påverkar ranking?

Bemästra din sidbläddring

En vanlig företeelse på webbsidor idag är någon form av sidbläddring. Det kan handla om kommentarer till en bloggpost såsom denna, eller en serie slides, en lång forum-tråd som delas upp på flera sidor med mera. Gemensamt är dock att alla sidor hör ihop och man vill signalera detta.

Det finns 3 sätt att lösa detta på varav det första inte kräver någon kunskap alls, du överlåter helt enkelt allt åt sökmotorn och förlitar dig på att den förstår att sidorna hör ihop. Detta sätt är absolut inte smartast, men ej heller sämst, något jag tar upp i exemplet längst.

Sidbläddring hos Google
Sidbläddring hos Google, ett vanligt förekommande fall att ange sidnummer.

2. Visa allt

Den första lösningen går ut på att du har en sida som kan visa allt innehåll från alla övriga sidor som ingår i gruppen. I fallet med kommentarer till ett blogginlägg skulle det således innebära att alla kommentarer visas på en och samma sida. För en forumtråd skapar man en sida som kan visa samtliga inlägg i tråden och så vidare. Det fungerar i vissa fall, i andra fall är det helt värdelöst. Här gäller sunt förnuft.

Att påpeka för sökmotorn att sidan som visar samtliga 1000 foruminlägg från tråden ska visas istället för en delmängd är inte alltför smart, dels blir laddtiden troligen lång, sidan blir enormt stor och besökaren hittar ändå inte vad som söks för att just det specifika inlägget drunknar i övriga 999 inlägg.

3. Link-taggen

html 4.01En smartare lösning är att använda <link>-taggen som introducerades i HTML 4.01 och ange relationen mellan sidorna. En relation anges genom attributet rel och sedan anges källan som vanligt i attributet href. I vårt fall är relationerna next samt prev det som är utav intresse, de talar helt enkelt om vilken nästa samt föregående sida är i hänsyn till sidan man har länken på.

Antag att vi har en grupp sidor som presenterar en vanlig Power Point-slide om hundar.
Den har 4 sidor och användaren har kommit till sidan 2, i HTML-sidans <head>-tagg lägger vi in vår speciella <link>-tagg för att ange relationen mellan sidorna så sökmotorerna enkelt kan förstå detta och slipper gissa. Följande kod borde synas i huvudet förutsatt man befinner sig på sidan 2.
<link href="http://www.example.com/presentation-hundar-1-av-4" rel="prev" />
<link href="http://www.example.com/presentation-hundar-3-av-4" rel="next" />

På första samt sista sidan kan du inte lägga in båda dessa taggar, det finns ingen sida före sidan 1 och det finns såklart ingen sida efter vår sista sida. Befinner du dig på sista sidan har du bara en relation till sidan efter (next)  och för sista sidan finns bara en föregående sida (prev).

Se upp

Som jag berättade i början av inlägget var en av lösningarna för sidbläddring helt enkelt att förlita sid på sökmotorerna och inte implementera någon speciell teknik alls. Jag har själv ett exempel på en sida som jag äger och utvecklar där jag lite klantigt nog blockerade sökmotorerna från att indexera mer än 1:a sidan. I mitt specifika fall hade det dock inte hjälp att göra den enkla lösningen, alternativ 1.

Sedan flera år har jag lagt in stöd på en av mina större sidor för att minimera duplikat innehåll genom att ange kanonisk sida. Det är ett kraftfyllt verktyg för att tala om för sökmotorn vilken av alla eventuella snarlika sidor som gäller. Min sida använder dels olika kampanj-länkar för att spåra när trafik kommer via mina mobil-appar, speciella nyheter o.s.v  men sedan länkar även besökarna till sidan. För att slippa få länkkraften utspridd samlar jag den enkelt till sidan som är rätt, trots alla extra parametrar som ibland anges på länkarna. Mer om just den problematiken finn i inlägget om kanonisk sida här ovan.

När jag sedan skulle införa tekniken för sidbläddring valde jag att jobba med relationer och ange dessa med <link>-taggar. På min webbsida där jag lyckades ha kvar mitt klantiga fel 8 månader kan besökarna skriva kommentarer till objekt. Tidigare visade jag bara de 30 senaste, nu ville jag dock att man även skulle komma åt alla äldre inlägg varav jag införde sidbläddringen.

Allt verkade frid och fröjd, min kod beräknade antal sidor rätt, den skrev ut relationerna helt korrekt och jag la upp förändringen på skarpa driftmiljön. 8 månader senare, jag hade fortfarande inte sett några tendenser till fel men jag ramlade över en artikel som tog upp vanliga misstag när man använde kanoniska sidor, något jag använder mig utav.

Det var då det slog mig, jag har kvar samma kanoniska sida oavsett om man stod på 1:a sidan eller ej. Min webbadress för varje objekt är enligt formen:
www.example.com/objekt/

När jag införde sidbläddring la jag på en parameter som talar om vilken sida man är på bland alla kommentarer, befinner man sig på sidan 3 blir adressen således:
www.example.com/objekt/?sida=3

För den som förstått allt resonemang ovan samt vet vilka tekniker jag använder kan säkert redan förstå mitt fatala misstag. Jag uppdaterade ju aldrig koden som skriver ut min kanoniska sidan.
Om vi återgår till sidan och håller oss till sidan 3, då såg min kanoniska sida ut enligt följande felaktiva format.
<link rel=”canonical” href=www.example.com/objekt/” />

Korrekt vore såklart att även ha kvar parametern för sidbläddring, rätt kod blir således:
<link rel=”canonical” href=www.example.com/objekt/?sida=3″ />

Så vad tror du misstaget medförde?
Sökmotorerna indexerade helt enkelt bara objekt-sidan och de 30 senaste kommentarerna som visas på den sidan. Även om jag anger med <link>-taggen att det finns fler sidor och dessutom har vanliga <a>-taggar anger jag ju på övriga sidor att sidan ej ska visas utan att objektets startsida bara ska visas. Jag har rullat ut min fix i skrivande stund och det blir spännande se hur många av alla nya sidor som kommer att indexeras.

Hur har ni sett att sökmotorer jobbar och presenterar sidor som hör ihop med sidbläddring?

Sökmotoroptimera din Ajax-sida

HashbangDet finns många anledningar till varför man skapar en sida som använder sig utav Ajax. Om du fortfarande vill få alla dina sidor indexerade gäller det dock att du kodar på rätt sätt. I dagsläget finns det två olika tekniker, hashbangs (#!) samt pushState varav den senare är att föredra.

Jag kommer inte ta upp alla fördelar Ajax-baserade webbsidor för med sig utan inlägget kommer endast fokusera på hur du måste göra för att fortfarande få fullgott stöd av indexering av sökmotorer.

Hashbangs (#!)

De flesta har nog sett implementationen av hashbangs på Twitter, det är när adressen innehåller de roliga tecknen (#!). Twitter har dock gått över till både permalänkar och nu senast den nyare varianten pushState vilket jag beskriver längre ned.

Hash-fragment
Allt efter # i en webbadress hör till hash-fragmentet och används oftast för att visa en specifik del på sidan. Vid Ajax-tillämpningar använder man dock denna del för att påvisa olika tillstånd av webbsidan.

Antag du besöker www.example.com/ajax#state=contacts, Ajax-logiken kommer då att extrahera all data ur fragmentet och visa rätt innehåll, i vårt fall troligen en sida med kontaktinfo.
Vad är då fördelen med att skapa dessa länkar med fragment? Jo, fragment hör inte till http-anropet och även om du byter tillstånd, det vill säga ändrar ditt fragment skickas ingen ny data fram och tillbaks till servern med automatik och du spar den tid det i vanliga fall skulle ha tagit att hämta all data.

Eftersom inget anrop görs per automatik för du bygga in hela denna logiken i din Ajax-lösning. Du kan till exempel bara skicka över all data som behöver förändras i lämpligt format (json) och slipper skicka med onödig overhead och filer.

_escaped_fragment_
För att sökmotorer ska kunna indexera din sida måste de dock göra lite extra bearbetning, de byter helt enkelt ut din hashbang mot _escaped_fragment_.
www.example.com/ajax#state=contacts blir www.example.com/ajax?_escaped_fragment_=state=contacts

Tack vare denna översättning av webbadressen kan sökmotorer fortfarande indexera din sida då adressen blir en gilltig url.

Sökmotorerna hämtar alltid sidan som innehar _escaped_fragment_, du måste således hantera alla dessa sidor och returnera en fullgod sida så som du vill att den ska se ut. Förslagsvis exakt så som motsvarande sidan med hashbangs ser ut, i annat fall bryter du mot riktlinjer och visar olika innehåll för användare och sökmotor.

I sökresultatet visar sökmotorerna alltid webbadressen med hashbangs, så dina fina länkar smutsat inte ned i onödan trots all översättnings som har gjorts.

Eftersom Twitter stödjer hashbangs för gamla länkar skull kan vi testa detta på min Twitterprofil.
Hashbangshttps://twitter.com/#!/stefanjanson
Escaped fragment för sökmotorerhttps://twitter.com/?_escaped_fragment_=/stefanjanson
Permalänkhttps://twitter.com/stefanjanson

I exemplet med Twitter måste de två första implementeras, den sista har de lagt till i efterhand och har inget med hashbangs att göra. På din webbsida och eventuell webbplatskarta ska den fina varianten av webbadressen användas. Länkar innehållande _escaped_fragment_ indexeras och följs ej.

Det värsta du kan göra är att returnera en felsida när example.com?_escaped_fragment= anropas, då kommer inget på sidan att indexeras…

 pushState()

En nyare och mer rekommenderad metod för att skapa Ajax-sidor som är anpassade för sökmotorer är att använda pushState() som hör till HTML5. Med denna metod kan man lägga till inlägg i webbläsarens historik-data genom att anropa history.pushState([data för sida], [sidans titel], [webbadress]). Exempel:

var stateObjekt = { minNyckel: "lite data..." };
history.pushState(stateObjekt , "sida 2", "ny-sida.html");

Objektet man kan skicka med till sidan är ett Javascript-objekt som erhålles när popstate-event avfyras. När användaren navigerar tillbaka till ursprungssidan saknas dock detta obekt då man ej skapat något, därför anropar man replaceState() vid första sidan. Hela kedjan blir enligt flödesschemat.

History API
Diagramet visar hur replaceState, pushState samt onPopState anropas

Precis som vid förändring av tillstånd i fallet med hashbangs sker inget http-anrop till servern utan det krävs egen logik för att hämta nödvändig data som ska presenteras. Antar att ni börjar förstå vitsen med Ajax-sidor, nämligen att man gör anropet själv för att hämta data.

Några fördelar med pushState gentemot hashbangs:

  • Du kan byta synlig url till vilken du vill så länge domänen är samma
  • Du kan skicka med ett eget objekt som erhållet vid alla sidbyten
  • Du kan skicka in samma url och det skapas ändå en ny post i historiken

Denna länk ändrar webbadressen m.h.a. pushState men du är fortfarande kvar på samma sida

Progressive enhancement

I båda fallen är det viktigt att koda enligt progressive enhancement. Väldigt kort betyder det att sidan även ska fungera för äldre webbläsare som ej stödjer all denna teknik och man bara adderar olika lager. Du kan till exempel bygga hela sidan som vanligt och sedan med javascript lyssna när någon klickar på en intern länk och då använda pushState() för att minifiera all dataöverföring och på så sätt förhöja besökarens upplevelse. Bara din fantasi sätter gränsen 🙂 Lite kodexempel baserat på jQuery som skickar dig i rätt riktning:

$('a').click(function(e) {
var url = $(this).attr("href");

//Anropa vår ajax-gateway som skapar minimal data
$.getJSON(”ajax-gateway.php”, {getPage: url},function (data) {
//Gör magiskt underverk med vår data
});

window.history.pushState(‘object’, ‘Sidans titel’, url);

//Stoppa vanliga klicket
e.preventDefault();
}

Det var ganska kort och väldigt tekniskt inlägg om två tekniker för att sökmotorer ska kunna indexera din webbsida om den baseras på Ajax. Inget för otekniska SEO-konsulter, rådfråga gärna en erfaren webbutvecklare 😉

Läs gärna min intervju med Västtrafik där de använder hashbangs.

När kakorna blir färre

CookieEn kaka är en liten textfil som en webbserver kan spara ned på användarens dator.
För annonssystem generellt kan kakor användas för att avgöra i slutändan hur mycket en visning utav en viss banner är värd och för affiliatesystem specifikt veta hur mycket publicisten skall få i ersättning.

Det finns olika typer av kakor, jag kommer bara ta upp de som kommer från 3:e part, en kaka där avsändaren kommer från en annan domän än den som användaren besöker.
Exempel: Du besöker www.example.com där en annons visas från ad.myexampleadnetwork.com som skickar med en kaka till webbläsaren. Eftersom domänerna skiljer sig är det tal om en kaka från 3:e part.

Kakor från 3:e part blockeras alltmer

I skrivande stund fungerar 3:e-partens kakor lite olika beroende på vilken webbläsare användaren sitter vid, alltfler webbläsare och program blockerar dock dessa.
Chrome: Alla kakor tillåts
Internet Explorer: I princip alla kakor tillåts med hjälp av P3P
Safari: 3:e parts kakor tillåts bara om det redan existerar minst 1 kaka från domänen
Firefox: Alla kakor tillåts, blockeras från version 22 som planeras släppas 25 juni 2013

Jag har frågat runt bland de största och för mig kända affiliatenätverken och här nedan är vad de har att delge om förändringen angående att 3:e-partskakor blockeras i allt högre utsträckning.
Här berättar de sin syn på hur blockerandet påverkar affiliate och annonsör.

TradeDoubler

När 3: e parts cookie blockeras kommer det att förhindra att isales / ileads spåras, detta har dock en liten inverkan på nätverket eftersom endast en liten mängd kunder betalar ut ersättning vid isales/ileads.

När det gäller Safari: cookie begränsning tillämpas endast på färska installationer av webbläsare och inte på uppgraderingar, dvs att gå från safari 5.0-5.1. Anledningen till att detta inte påverkas är att för att de utgår från de äldre versionerna.

Många program på vårt nätverk använder 1:a Part cookies ändå så det skall vara opåverkat. Safari 5.1 står för mindre än 5% av alla webbläsare som används och mindre än 2% för EU. Du kan se detta på länken nedan

Firefox och våra första test har inte visat någon effekt på post click tracking, det har blockerat cookies som sätts innan ett klick görs. Hela industrin är på väg bort från 3: e parts cookies på grund av förra årets e-privacy direktiv. Vi har även ”cookie lösa” lösningar som IP-användaragent och andra metoder som är under utveckling men är för tillfället konfidentiella.

WordOn

För WordOn’s del så arbetar vi med många sorters spårning.
Vanligtvis gäller det bannerannonsering på webbsidor där användaren skall klicka på en annons för att visa intresse. Detta gör att användaren faktiskt besöker WordOn’s webbsajt innan vi skickar användaren vidare till annonsören och därmed kan vi sätta en första klassens kaka på användarens dator.
Ett annat alternativ som vi använder är spårning utan kakor. Då skickar vi motsvarande information som skulle ligga i kakan till våra kunder och denna referenser rapporteras sedan tillbaka när köpet genomförs. Även här så krävs det förstås ett klick och ställer med krav på att annonsören faktiskt hanterar referensen.

För de fallen där man behöver spårning utan klick men inte har möjlighet att sätta kakor så finns det ju alltid alternativ eftersom varje webbläsare lämnar vissa fingeravtryck. Informationen kan då lagra på server sidan. Ett exempel på när detta tillämpas är där man vill ge en annan ersättning för köp om användaren bara sett annonsen än ifall användaren skulle ha klickat sig fram. Detta skulle ju förstås ha underlättats av 3’e parts kakor.

Sammanfattningsvis så påverkas inte WordOns verksamhet i dagsläget i större utsträckning av ändringen men vi följer utvecklingen med största intresse.

Adrecord

Vi jobbar med både förstapartscookies och tredjepartscookies hos våra annonsörer, ca 60% sätter själva en förstapartscookie för vår spårning.

Oavsett om våra annonsörer kör med egen eller vår cookie så bör cookies kompletteras med andra mätmetoder och det är något vi har diskuterat under en längre tid och kommer att införa i större skala inom kort. Hur vi jobbar och hur vår teknik fungerar i detalj kan jag av konkurrensskäl inte gå djupare in på, men det finns mycket att skruva på under huven i webbläsarna.

Vi har fått frågor kring detta vid ett flertal tillfällen de senaste åren och har haft ämnet uppe för diskussion oftare än så. Det ligger självklart i vårt intresse att kunna spåra så nära 100% som möjligt och våra affiliates och kunder ska känna en tillförlitlighet att vi varken spårar mer eller mindre.

Zanox

Den överlägst största delen av alla kakor som används av Zanox för att spåra lead och sale hanteras tekniskt som 1:a partens kakor vilket tydligt innbär att det inte påverkas av några av dessa förändringar.

Mozilla jämför förändringen med Safari och dess strategi för kakor. Safaris policy för kakor har varit i drift i över ett decennium och både användarna och reklambraschen är vana vid att arbeta enligt detta sätt.

Givetvis håller vi på med efterforskning, tester och utveckling för att minimera eventuella negativa effekter på vår spårningstjänst för annonsörer och publicister. Vad vi redan antar är att speciellt annonsörer som använder en extern spårningslösning (external tracking switch), som sätter 3:e partens kakor kommer att påverkas.

Adtraction

Traditionell affiliatemarknadsföring påverkas inte nämnvärt av detta eftersom klicken studsas från affiliatesajten via en spårningsserver till annonsören. Cookies sätts i det korta ögonblick som besökaren landar på spårningsservern och dessa utgör därmed förstapartscookies.

Double

Vi använder inte tredjepartscookies för spårning av leads och sales då all trafik går via vår domän. Tredjepartscookies används generellt vid annonsvisning för att spåra besökare vilket vi inte gör.

 

Avslutningsvis

Det verkar inte som att affiliates kommer att påverkas i någon märkbar grad, det skulle vara i de fall så man tjänat pengar på iLead/iSale vilket åtminstone till en början ej kommer vara möjligt.

Som annonsör kan man mista lite mer detaljerad statistik, men inte heller här sker några större förändringar.

Jag rikta ett stort tack till de affiliatenätverk som ställde upp och gav sin syn på förändringen med 3:e partens kakor.

Google varnar för Djurgården Fotboll

Ibland kan saker spåra ut, ungefär som när Djurgårdens Fotboll oskyldigt råkat ut för spam via pingback och länkar till alla möjliga sidor som de säkerligen inte vill förknippas med. Det har gått så långt att Google skriver ut varningar till att besöka vissa av deras sidor.

Google varnar för spam
Google varnar: ”Denna webbplats kan vara osäker att besöka” 470 sidor matchar sökförfrågan…

Så vad är det som hänt DIF och hur har de kunnat förhindra att detta ens uppstod från början?
Med all sannolikhet har kommentarer varit omodererade, och kanske fortfarande är detta. Bara för att man använder ett externt system för kommentarer innebär inte det per automatik att det inbyggda i WordPress inaktiverats. Människor av den mindre formen av snälla har helt enkelt skickat fejkade pingbacks till diverse blogginlägg. Dessa har publicerats och på så sätt skapat en länk till målsidan.

Även om länken är nofollow, så kan vi tydligt se att det gjort stor skada genom att varningsmeddelande presenteras för Google-besökarna och att ord som man ej vill förknippas med står rakt i koden.

Genom att inaktivera javascript kan vi enklare se all spam som finns till ett blogginlägg hos dif.se och det handlar om hundratalet spam-länkar enbart till ett inlägg.

Pingback-spam
Länkarna syns tydligt när javascript är inaktiverat och Discuss ej visas

Driver man en webbsida måste man täppa till alla tänkbara sårbarheter, även de mer oskuldsfulla kommentarerna till bloggar. I detta fallet hade det undvikits om pingbacks inte tilläts automatiskt, för jag är tveksam till att Dig själva släppt igenom dessa hundratals länkar på en enda bloggpost. Inställningar för allt relaterat till kommentarer och pingbacks hittas under Inställningar -> Diskussion.

Använder man WordPress är tillägget Akismet en guldgruva mot spam, det följer dessutom med som standard. För privatpersoner är det gratis att använda och ju fler kommentarer du taggar upp felaktigt klassificerade desto bättre blir Akismet.

Webmaster tools

Google erbjuder ett förträffligt verktyg helt gratis, Verktyg för webbansvariga. Jag ska bara nämna en av alla funktioner detta verktyg medför till validerade webbplatser, meddelanden. När Google upptäcker något skumt med sidan skickar de ut ett meddelande, det kan t.ex. handla om att sidan verkar ligga nere, den har fått många nya 404-sidor, sidan verkar ha blivit hackas med mera.
Med all sannolikhet hade Google skickat ut en varning angående ovanstående spam-problematik och Djurgärden Fotboll hade upptäckt deras problem för länge sedan.

Varningsmeddelanden
Tack vare varningsmeddelandet upptäckte jag att min sida blivit hackad och åtgärdade problemet snabbt.

Det är inte bara gamla inlägg som är drabbade, gör vi en sökning och sorterar på datum visas det senaste från 23 januari 2013. Så ett gott råd till DIF och alla med bloggar därute, se upp med era kommentarer om de är aktiva.

Färska resultat också drabbadeJag har givetvis kontaktat Djurgårdens Fotboll och inväntar svar, förhoppningsvis åtgärdas detta snabbt och Google tar bort alla varningsmeddelanden.

Ett annat bra tips till webbutvecklaren hos DIF är att använda float:left på twitter-rutan så att den inte blockerar hela rutan sociala medier. Som det är nu kan man inte klicka på senaste blogginlägg varken i Chrome eller Firefox…

Länkbomber – fakta och teorier

LänkbombLänkbomber, eller Google-bomber, som de oftast kallas handlar om att skapa ett stort antal länkar och få upp en sida på en sökfras och/eller sökord som är helt orelaterat för den specifika målsidan.

Som med mycket annat har diskussionen om huruvida detta fenomen fortfarande fungerar eller ej blossat upp, nu senast om urbota inskränkthet. Nikke Lindqvist var nog den enda(?) som uttalade sig att länkbombning inte längre fungerar medan Urban Grotherus tvärtemot påpekade att det visst fortfarande fungerar. Däremellan fanns flertalet människor som hade sina åsikter fast väldigt få, om ens någon, backade upp alla sina teorier med någon som helst fakta. Förutom testet om Miljöpartiet och att få den ranka för en sökfras.

Själv höll jag mig mer åt Nikkes linje där jag ställde mig tveksam till om detta fortfarande hade samma påverkan som tidigare. Att jag dock påpekat att det inte fungerar alls vill jag inte minnas att jag skrivit någonstans, har jag gjort det tar jag tillbaks det och hänvisar till inlägget om min tveksamhet. Jag hävdar fortfarande att Googlebomber inte längre fungerar i samma utsträckning då det finns algoritmer för att motverka samt blockera dessa, något jag vetat om långt innan diskussionen ens blossade upp helt nyligen. Dessa algoritmer för att hitta länkbomber körs dock bara ibland, vilket bevisas längre ned.

Jag vet att utan något officiellt uttalande eller analys av källkod är det omöjligt att ens gissa sig till hur länkbombning fungerar. Att utföra tester behöver dock inte bekräfta saker, som Magnus Bråth själv efterlyste behövs mer vetenskapliga metoder inom SEO, något jag hoppas även han tar till sig och inte bara förespråkar. Detta är mitt försök att bidra med en annorlunda analys av länkbomber som baseras på uttalanden från Google och mer vetenskaplig synvinkel av ett test.

Testet bekräftar inget och kan aldrig göra det

Hur många tester man än gör angående länkbomber kan man aldrig bekräfta att länkbomber fungerar, det enda du kan uppnå är att påvisa att sökmotorer har filter som motverkar dess uppkomst. Förklaringen baseras på vetenskap, det vill säga hur logiska tester går till och vilka resultat som kan bli dess utfall.

Länkar har sedan urminnes tider alltid varit kärnan i hur sökmotorer inbördes rankar sidor i deras listning. Till detta finns ett otal andra faktorer, dessa är inte intressanta i detta specifika test. Ankartexten, det vill säga texten som är själva länken, är en stor signal på vad målsidan bör ranka på. Länkar man till en sida med frasen ”urbota inskränkthet” börjar den givetvis ranka på detta, något annat vore konstigt om inget tydligt uttalande gjorts då hela grunden som sagt bygger på länkar. Länkbomber är som namnet antyder vanliga länkar, skillnaden är att man har en ankartext som inte är relevant för målsidan. Länkbomber är alltså länkar, så hur ska du någonsin kunna bevisa att länkbomber fungerar när det innefattar länkar. Om beviset ens ska vara giltigt måste det från början ha varit bevisat att du inte kunnat ranka en sida med en ankarlänk som är orelevant för sidan. Om ni fortfarande inte hänger med får ni nog läsa om stycket alternativt läsa mer om hur man gör vetenskapliga tester.

Testet kan däremot påvisa motsatsen, det vill säga att länkbomber inte alls fungerar på samma princip idag som det förr gjorde. Om miljöpartiet slutar ranka för sökfrasen eller hamnar långt ned, då är utfallet av testet att länkbomber inte fungerar som tidigare och att det finns filter. Det senare beviset är dock förenklat och är mer komplicerat då ranking baserar på fler faktorer än länkar, till exempel har flertalet spamlänkar tillkommit.

Officiella uttalanden

För dom som fortfarande läser och ändå tror att testet kan bevisa länkbombens existens, eller för den delen fortfarande inte tror att länkbomber fungerar kommer här länkar till officiella uttalanden från Google. Vad dessa har gemensamt är att de bekräftar att länkbomber fungerar men att det finns algoritmer för att hitta dessa. Algoritmer kan aldrig fånga upp 100% och just vid länkbomber körs dessa bara vid ett fåtal gånger per år för att upptäcka nya, när en dock upptäckts körs filtret vid varje sökning. Vetenskapliga metoder efterfrågades, ändå ropar folk att testet bevisade att länkbomber fungerar, när testet knappt körts en vecka. Sannolikheten att algoritmen för att upptäcka länkbomben ens har körts är ganska liten, till detta upptäcks inte 100% av alla länkbomber.

Jag är inte verksam inom SEO, men att göra källgranskning och vetenskaplig undersökning är jag desto bättre på efter 5 års studier på Chalmers. Folk får gärna komma med sina egna reflektioner, detta var mitt försök att få en annan bild av hela diskussionen och som baseras på officiella uttalanden och vetenskaplig fakta om hur tester fungerar. Det publiceras mycket information och det kan säkert ha kommit fler uttalanden, att det förändrar hur länkbomber fungerar eller ej tror jag dock inte. Skriv gärna i kommentarerna och länka in fler källor om ni besitter sådana.

Summa summarum, länkbomber fungerar eftersom länkar fungerar, det finns dock algortimer för att hitta en stor del av de som påverkar sökupplevelsen som mest. Sedan får folk ha sina teorier och åsikter bäst de vill 🙂