Månadsarkiv: mars 2013

Chalmers bibliotek om deras nya webb, synlighet samt sociala medier

Chalmers Bibliotek på en Nexus 7Berätta lite kort om vilka ni är och vad ni har för arbetsuppgifter.
Teamet som har arbetat med bibliotekets nya webb består av 4 systemutvecklare och 4 bibliotekarier med olika inriktning som webb, systemutveckling, söktjänster, sociala medier och grafisk design. Alla är anställda på Chalmers bibliotek.

Kollade på er Youtube-kanal och ni verkar ha bytt CMS-system till Umbraco, hänger det ihop med övergången till responsive design eller vad var huvudsyftet med bytet?
I ett tidigare projekt i vilket vi tog fram ett nytt intranät för biblioteket, lärde vi oss mer om .Net och SharePoint. Vi tog vara på lärdomarna från intranätsprojektet och insåg att SharePoint var ett mindre lämpligt val för en helt publik webbplats. Efter att ha utvärderat en rad olika webbplattformar föll valet på Umbraco som också kör i .Net-miljö. Vi har idag stor glädje av att kunna använda vår kunskap och erfarenhet kring .Net för båda tjänsterna. Övergången till den responsiva designen har inte påverkat valet av CMS.

Vad var målet med att ta fram en ny plattform för er webbsida?
Målet var att skapa en lättanvänd webbplats som lyfter fram de tjänster våra användare har behov av. Ett av våra motton var en uppgiftsorienterad webb – ett serviceorgan, att komma till vår webbplats och snabbt kunna uträtta det man vill få hjälp med. Att man skall känna sig välkommen att kontakta oss och få hjälp. Vi ville också att den skulle kännas modern, innovativ och att det skulle vara en trevlig användarupplevelse att använda den.

Bibliotekets hjärta är alla informationsresurser vi förmedlar. Söktjänster, databaser, böcker, tidskrifter, artiklar m.m. De är från en mängd olika leverantörer med olika gränssnitt. Vi ville underlätta åtkomsten till denna mängd genom att lyfta fram och konsolidera söket och erbjuda en enkel sökingång som täcker nästan allt vårt material, en sökingång som följer med och man lätt hittar överst på varje sida.

Vi ville också att man skulle kunna använda webbplatsen oberoende av device – därav den responsiva designen.

Vi gjorde en gedigen användarresearch i början av projektet och på grundval av den skapade vi tre personas som vi designade webben för. En student i början av sina studier, en mer erfaren i begrepp att skriva examensarbete samt en forskare.

Finns det några speciella krav sidan måste uppfylla (språkstöd för utbytesstudenter, blindskrift osv)?
Vi hade som mål att den nya webben skulle stödja tillgänglighet så långt som möjligt, men med fokus på att den skulle fungera för skärmläsarprogramvaror. Något som inte var helt lätt eftersom det finns många olika tillgänglighetsrekommendationer och en del känns daterade och skärmläsare klarar mer och mer vartefter de utvecklas. Vi har tittat på Vägledning för webbutveckling, WCAG 2.0 och kommersiella aktörer som Funka nu och försökt plocka ut det mest essentiella.

Tyvärr har vi inte kommit ända fram, men vi tror att vi kommit en liten bit på väg genom att använda standarder så långt som möjligt, försökt stödja navigering via av tangentbord, och visuellt dolda genvägar för navigering. Webbyrån har också testat att huvudparten av webbplatsen går att använda med den skärmläsarprogramvara (SuperNova) som Chalmers idag erbjuder funktionshindrade som har behov av en sådan.

Hur har samarbetet med Dear Friends fungerat? Vad gjorde ni inhouse respektive la ut på konsultjobb?
Vi har arbetat rätt oortodoxt gentemot webbyrån Dear Friends. Vi hade ingen sedvanlig kravspecifikation – av flera skäl. Dels tidsmässiga, men framför allt att vi inte tror på vattenfallsmetoden och ville arbeta agilt även med design, interaktionsdesign och innehåll av webben. Det har ställt annorlunda krav på oss som beställare, men även på webbyrån. Ingen av oss hade en detaljerad kravspecifikation att peka på när det gäller vad vi beställt. Det har gett upphov till diskussioner, men också till ett närmare samarbete där båda parter kommit med idéer, feedback men också möjligheten att tänka om under arbetets gång.

Dear Friends har ansvarat för design, interaktionsdesign, responsiv webbdesign och gränsnittskodning. Biblioteket har stått för användarresearch, innehållsarbete, användartester, implementering i CMS:et Umbraco och allt backendarbete mot olika API:er och feeds.
Mer om vårt arbete med webbyrån finns i en bloggpost.

En framgångsfaktor i projektet är att vi har tillgång till egna utvecklare på biblioteket som har stått för implementeringen. Vi har inte hamnat i den svåra situationen att ha en konsult för design och en annan för implementering som kan ge upphov till svåra ansvarsgränsdragningar och att man kommer i otakt när det gäller tid och resursplaneringar till projektet.

Ni jobbade agilt med projektet, berätta lite hur det gått till och hur det har fungerat.
Systemutvecklarna på Chalmers bibliotek använder SCRUM-metodiken, (http://sv.wikipedia.org/wiki/Scrum), en agil metod som blir allt mer vanlig i teknisk systemutveckling. Däremot är den inte lika vanlig när det gäller utveckling av scope, UX, visuell design, interaktionsdesign och innehållsarbete. I det här projektet har vi provat SCRUM för hela teamet – även UX-delarna och att försöka få alla delarna integrerade med varandra. Det är en större utmaning än att använda SCRUM endast för den tekniska utvecklingen. Vi lär oss hela tiden och det underlättar att SCRUM har en ofta återkommande, inbyggd utvärdering i form av sprint retrospective, i metodiken.

Vi har delat upp arbetet i ett antal 14-dagarssprintar, börjat med sprint planning och avslutat med sprint demo och retrospective.

När jag studerade på Chalmers (02-07) fanns CTK, fanns några planer att anlita dom, är de borta eller hur gick tankebanorna?
Vi anlitade en av de byråer Chalmers har upphandlat och som hade designat den nya Chalmers.se. Vi var först intresserade av att anlita CP+B Europe som då precis hade blivit upphandlade och som vissa i webbgruppen hade positiv erfarenhet av sedan tidigare men det var för tidigt. Frågan om hur vi skulle kunna använda oss av chalmersstudenter har emellertid varit uppe.

Sveriges första bibliotekssajt med responsive design, måste kännas underbart med tanke på er målgrupp?
Ja, det känns väldigt kul att vara tidigt ute med att lansera en responsiv webbplats. Speciellt med tanke på att trenden visar att fler och fler använder andra devicer än desktop och då är vi förberedda och ger en lösning som är någorlunda deviceoberoende.. Vi kommer självklart att utvärdera hur responsiv design fungerar, vad en sådan design löser. Och vad den inte löser – t.ex att allt innehåll kanske inte passar för mobil användning. Där skulle det vara spännande att fortsätta ett projekt med adaptiv design.

Har ni en stor andel besökare som kommer in via mobil respektive surfplatta och är det uppåtgående trend?
Idag är det bara ca 5% av besöken som kommer från mobila enheter. Det är för tidigt ännu för att se om vår nya webb ökat antalet mobila besök. Från oktober 2012 kan man se att antalet mobila besök började öka på den gamla webben. Vi har haft en mobil app som nu avslutas i och med lanseringen av den nya responsiva webbplatsen. Det kanske kommer att leda till en ökning av mobila besök till webben.

Många företag jobbar med synlighet på sökmotorer, sökmotoroptimering, är det något ni också kikat på?
Vi har arbetat aktivt med sökmotoroptimering för andra webbtjänster som förvaltas av Chalmers bibliotek, t ex Chalmers publikationsdatabas CPL. Chalmers biblioteks nya webbplats har dock inte optimerats på samma sätt men det är något vi ska titta närmare på framöver. Vi tar gärna emot tips och goda råd från er på SEO-bloggen.

Såg att ni använder Googe Analytics, gör ni några analyser eller används det mest för att se antal besökare?
Fram till nu har vi mest använt Analytics för att se antalet besök, varifrån trafiken kommer osv. På den nya webben kommer vi att jobba mer med Analytics.

Ni återfinns på Facebook, Twitter och Youtube, har ni något strategi för arbetet här eller används det mest för att nå ut till intresserade?
Ja vi har en strategi. Varje kanal har mätbara mål, målgrupp, syfte och målen är kopplade till bibliotekets verksamhetsmål.

Har ni funnit länge på respektive media och vilken anser ni ge mest engagemang?
Vi har funnits på Facebook, Twitter, YouTube och en WordPressblogg sedan hösten/vintern 2010. Bloggen och Twitter är det som gett mest utdelning när det gäller att sprida vårt varumärke bland kollegor i landet och nå ut till studenter och forskare.

Några nya intressanta projekt på gång?
Vi lanserar snart (påsk) en ny söksajt som ska göra det lättare att hitta studentarbeten, läs mer: http://blog.lib.chalmers.se/2013/03/01/storre-synlighet-for-chalmers-studentarbeten/

Förhindra duplikat innehåll med en kanonisk sida

Duplikat innehåll kan lätt uppstå och kan orsaka problem hos sökmotorer, det ska dock påpekas att de är ganska smarta nuförtiden. Med det sagt förhindrar det inte oss ifrån att använda de tekniker som finns tillgängliga för att påtala för sökmotorerna vilken sida det egentligen är som gäller bland flera snarlika.

Enkelt uttryckt är duplikat innehåll, eller duplicate content, som det heter på engelska en bieffekt utav att flera olika länkar presenterar samma sida och innehåll. Vi kan ta Göteborgs-Posten som ett typexempel som har detta problemet.

Duplicate content hos GP.se
Senast felaktigt indexerade filen skedde bara för 1 dag sedan

På varje sida hos GP.se finns det funktioner för att dela till Facebook och Twitter. För att enkelt mäta effekten av hur många besökare de erhåller läggs det därför på en kampanj-parameter på länken. Följande 3 länkar går alla till samma innehåll, men det är bara den översta som borde väljas att indexeras av sökmotorer, de andra skapas enbart när man delar sidan via sociala medier och e-post.

http://www.gp.se/nyheter/1.1081975-luras-med-falska-apple-sms
http://www.gp.se/nyheter/1.1081975-luras-med-falska-apple-sms?ref=fb
http://www.gp.se/dela/1.1081975-luras-med-falska-apple-sms

Båda de två typerna av länkar har indexerats av Google, det handlar i skrivande stund om 5700 sidor som blivit felaktigt indexerade och där man genom en enda kodrad kan rätta till felet.

rel=”canonical”

Genom att skapa en kanonisk sida talar man om vilken av av alla sidor som är den föredragna. Det finns i dagsläget två olika sätt att skapa en kanonisk sida.

Lägg till rel=”canonical” i html-kodens <head>
Genom att lägga in en rad html-kod i de sidor som inte är huvudsidan, påtalar du för sökmotorerna att du föredrar sidan du länkar till. I vårt exempel med Göteborgs-Posten ska de således lägga in följande i sidans huvud. Det skadar inte att även ha koden på den prioriterade sidan även om det är onödigt.
<link rel=”canonical” href=”http://www.gp.se/nyheter/1.1081975-luras-med-falska-apple-sms” />

Svara med rel=”canonical” i HTTP-huvudet
Denna variant är mer teknisk och kräver tillgång till din webbserver, den passar bra för indexerade filer som ej använder sig utan HTML, till exempel PDF-dokument. I HTTP-huvudet skickar du med länken till din föredragna variant av filen, precis som i exemplet ovan. Våra exempelsidor bör således svara med följande extra header i HTTP-huvudet.
Link: <http://www.gp.se/nyheter/1.1081975-luras-med-falska-apple-sms>; rel="canonical"

Ovanstående header kan skapas på flertalet sätt, ett exempel skrivet i PHP ser ut enligt:
<?php
header("Link: <http://www.gp.se/nyheter/1.1081975-luras-med-falska-apple-sms>; rel=canonical");
?>

Värt att tänka på är att rel=”canonical” ses som ett förslag till sökmotorer och är inget de måste följa, av erfarenhet har jag dock sett att de ofta litar på detta tips.

Om du flyttar innehåll och vill skicka vidare besökaren direkt till en annan adress är en kanonisk sida inte rätt väg, då ska du kika på 301-redirect som är ännu en header som kan anges i HTTP-huvudet. Återigen, om sidan använder PHP kan man t.ex. skriva följande i koden:

<?php
header ('HTTP/1.1 301 Moved Permanently');
header ('Location: http://www.exempel.se/ny-sida');
die();
?>

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.

Västtrafik och hashbangs

VästtrafikVästtrafik har ganska nyligen lanserat en ny webbsida som de har jobbat med under några års tid. Det var en stor förändring och sidan fick blandat mottagande i början, hur som använder den lite ny fräck teknik och jag ville såklart intervjua projektledaren Mikael Faleke.

Berätta gärna lite kort om vem du är och vad du har för roll
Webbansvarig på Västtrafik sedan 12 år tillbaka. Är den som tagit fram den nya hemsidan i rollen som projektledare.

Ni gjorde relativt nyligen om hemsidan för Västtrafik, vad var det huvudsakliga målet med arbetet?
Visa på hur lättillgängligt det är att resa med Västtrafik, locka nya målgrupper att prova kollektivtrafiken. Men nya målgrupper menar vi för hemsidans del bilister som bor så att de har bra kollektivtrafikalternativ.

I början var det ganska högljudda åsikter om sidan, har det lagt sig nu när folk vant sig med allt nya?
Nästan ingen gillar förändringar. Så oavsett vilken hemsida du bygger om så blir det åsikter. Titta till exempel på när Facebook ändrade sin timeline. Det hör till. Hade blivit mer förvånad om vi inte fått några reaktioner alls. Eftersom drygt 95 procent av våra besökare är återkommande så ställde vi ju till det för dem och de fick lära om. Men visst – jag börjar bli lite trött på ”gör om – gör rätt”. Vi har gjort om och vi har gjort rätt. Tyvärr är sidan inte vidare mobilanpassad och det är något vi ska ha kritik för. Vi jobbar med det just nu. Men i övrigt fungerar det bra.

Sidan använder sig frekvent av Ajax, fanns det med i ert krav eller vad är de främsta anledningarna till att utnyttja denna teknik?
För att få en sömlös upplevelse där det inte upplevs som att sidan laddas om utan enbart att informationen byts ut så valde vi den tekniken. Det var inget krav från början utan det blev lösningen.

Sökmotorer kan ha problem med att indexera sidor som byggs upp via Ajax om det inte gjorts på rätt sätt, ni har dock fått till tekniken med hashbangs (#!) och escaped_fragment-stödet. Kanske lite väl tekniskt, men var det ett krav från er eller hjälpte Know IT er även med detta?
Detta är något som vi får tacka KnowIT för. De ledde in oss på det spåret. Vi har dessutom byggt upp en parallell sida som inte använder Ajax och som funkar för äldre webbläsare. Den är enklare för Google att indexera.

Även en rätt ny teknik som använder sig av pushState fungerar väl för Ajax-sidor, är det något som även tog upp för diskussion? Arbetet med webbsidan har hållt på under flera år så den tekniken kanske inte var tillräckligt utbredd på den tiden.
Nej, vi började ju redan 2010 med sajten så vi missade flera nya tekniker, till exempel responsiv webbdesign och pushState. Vi använder annan teknik för att få bakåtknappen att fungera i webbläsaren. När vi första gången såg designidén från vår samarbetspartner Forsman&Bodenfors så tog jag mig för pannan och sa att det kommer aldrig att gå. Då saknades ramverk att bygga med så det blev väldigt mycket grundarbete innan vi hade en första fungerande prototyp. Idag är detta inte raketvetenskap utan betydligt enklare att uppnå.

Några andra intressanta saker du vill ta upp som ni stött på under arbetets gång med webbsidan?
Att det finns alldeles för många webbläsare J Skämt åsido – vi skulle lanserat tidigare än vad det blev och orsaken till detta är att det tog både tid och pengar att anpassa för olika webbläsare. Till slut fick vi sätta ner foten och bestämma att äldre versioner av Internet Explorer får använda en enklare version av sidan. Man kommer automatiskt till denna om man har javascript avstängt i webbläsaren. Den stora skillnaden mellan de två sajterna är att den enkla saknar kartbakgrunden.

Stor tack till Västtrafik och Mikael Faleke!

Missa inte heller inlägget som tar upp två tekniker för att sökmotoroptimera din Ajax-sida.

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.

Ta vara på gamla produktsidor

Alla som bedriver butiker online känner säker igen sig. En produkt ska inte längre säljas, vad ska jag nu göra? Det uppenbara är att helt enkelt radera sidan, det bidrar dock med en hel hög negativa aspekter både för dig seo-mässigt och för besökarens användarupplevelse.

Att en produkt tas bort kan ha många anledning, i detta inlägg ska jag dock förklara hur du på ett bra sätt bör gå tillväga med din gamla produktsida.

404 hittades ej
En dåligt utformat 404-sida ger inget bra intryck

1. Behåll sidan

Grundprincipen är att du aldrig ska ta bort en sida. Ofta har du lagt ned energi på att få sidan ranka, det du måste göra är dock att informera besökaren om att produkten har utgått och att den ej kan beställas längre. Om produkten ersatts med annan produkt, eller liknande produkt finns så informerar man lämpligen besökaren om detta och länkar till dessa produkter.

2. 301 redirect

Om du verkligen måste ta bort sidan, se till att skicka besökaren till den ersatta produkten alternativt en snarlik produkt. Om dessa två fall ej är möjligt skicka vidare besökaren till produktkategorin. Det finns två stora vinster med detta förfarande, dels slipper du brutna länkar in till din sida men framför allt slipper besökaren hamna på en felsida och du kan fånga upp intresset för en snarlik produkt.
I varje fall där du skickar vidare besökaren med 301 redirect bör du informera besökaren om varför man ej hamnade på sidan man förväntade sig.

Så hur vet du om besökaren kommer till en produktsida/kategorisida genom ovan nämnda redirect?
Det finns 3 olika sätt att lösa det på, vilket du väljer beror till stor del vad som är tekniskt möjligt med just din webbutik.

1. Skicka med en parameter
När du gör din redirect, se till att slänga på en extra parameter som talar om att besökaren kommer från en borttagen sida, det kan förslagsvis vara produktens id från databasen.
www.example.com/category/name -> www.example.com/name?removedproductid=123

Eftersom du lägger på en extra parameter måste du se till att målsidan är en kanonisk sida, i vårt exempel ska således följande kod finnas i sidhuvudet på kategorisidan för att undivka duplikat innehåll.
<link rel="canonical" href="www.example.com/category/name"/>

2. Använd sessioner / cookies

När besökaren kommer till en produkt kan du sätta en sessionvariabel innehållandes produktens id. Kategorisidan kan då se att variabeln är satt, ta bort denna samt informera användaren.

3. Användarvänlig 404-sida

Om du inte ser en annan utväg eller om ovanstående inte passar för just din borttagna sida, skapa då en användarvänlig 404-sida. Bara för att en webbsida har 404 satt i http-huvudet betyder inte det automatiskt att det måste stå stor och fult ”404 – Sidan hittades ej”.
Tvärtom, du kan designa upp denna sida precis hur du vill, du kan till och med presentera information baserat på vilken sida som tagits bort, vilken länk man kom via eller kanske vad klockan är. Bara din fantasi sätter gränserna.

Vad du än gör, skapa inte en tråkig 404-sida som är standard på de flesta webbservrar om du vet med dig att sidor kommer tas bort på regelbunden basis.

Produktkyrkogård

Ett roligt sätt att ta vara på alla gamla produkter som behövt raderas är att samla dom under en produktkyrkogård. Dels kan det skapa lite extra länkar till er webbsida, sedan kan nostalgiska besökare läsa om alla utgångna produkter, du kan till och med lägga till lite extra data om när produkten funnits. Ett tappert försök har Ben&Jerry gjort med deras kyrkogård, något jag fick syn på efter ett inlägg av Sökmotorkonsult och som de verkade gilla.

Helt bra exempel är det dock inte seo-mässigt.
Dels fungerar inte de gamla länkarna, kyrkogården är dessutom helt baserad på flash. Vitsen är ju att de gamla sidorna ska vara kvar och fungerande. Mobil-varianten av deras sida har samma brister förutom att den inte är skapad i flash. Som en vis man sagt till mig. Aldrig, aldrig ta bort en sida.

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…