Affiliatesystem Suger, Så Vi Skapade Ett Eget

Låt oss vara helt ärliga; de flesta affiliatesystem på marknaden är rent förfärliga. Antingen är de mycket förvirrande, klumpiga och långsamma, eller så ser de ut som om de var utformade på 90-talet. Eller värre, en blandning av alla ovanstående. Vissa kan ha hälften av de verktyg du behöver men sedan saknas andra viktiga funktioner som din affiliatemarknadsförare vill ha. 😩

Sedan vi lanserade Kinsta har det varit vårt uppdrag att aldrig släppa något undermåligt till våra kunder. En standard vi upprätthåller är att om det är något vi inte skulle använda oss av själva, då måste vi hitta ett bättre sätt. Så precis som vi gjorde med vår MyKinsta-panel, bestämde vi oss för att bygga vårt eget.

Idag ska vi diskutera några av anledningarna till att vi tog denna rutt, både från ett affärs- och utvecklingsperspektiv, liksom vad vi fick på slutet (från MVP till slutprodukten).

• Varför Vi Skapade Vårt Eget
• Grunderna i hur vårt Affiliatesystem fungerar
• MVP (Börja bygga)
• Ändra MVP (Anpassa och göra förbättringar)
• Slutprodukten
• Affiliatesystemet och Programmet i Action

Varför Vi Skapade Vårt Eget

När vi började undersöka vad som behövde göras för att implementera ett affiliatesystem insåg vi snabbt att det inte fanns någon färdig lösning för oss. Här är de främsta anledningarna till varför:

• Det största problemet var att vårt affiliatesystem behövde vara tätt kopplat till våra planer och prenumerationssystem, inte med en tredjepartsleverantör.
• Branding är mycket viktigt för oss. Medan vissa affiliatesystem erbjuder vitmärkningslösningar, är de flesta av dem halvbra implementeringar och inte alltid helt transparenta. Att bygga det själva skulle ge oss full kontroll över design och branding, utan att behöva oroa oss över vitmärkningslösningar överhuvudtaget.
• Att förlita oss på ett system från tredje part skulle hindra oss från att lägga till nya funktioner snabbt eller alls. Största delen av vår anpassade MyKinsta-panel är byggd helt från användaråterkoppling, och det är därför det har blivit ett av de bästa WordPresswebbplats-hanteringsverktygen i branschen! Tack vare våra fantastiska kunder.  👏Vi visste att om vi lanserade med en lösning från tredje part, skulle feedback och förfrågningar börja flöda in, och vi skulle inte ha möjlighet att få dem att hända.
• Möjligheten att tillhandahålla och bygga anpassad rapportering, inte bara för våra affiliates utan också för våra administratörer var något vi inte kunde leva utan. Vi älskar och behöver data! Hur ska du annars fatta strategiska beslut framåt? Att dra rapporteringsdata måste också göras från våra komplexa planer och prenumerationssystem.

Vi grävde i detta lite mer, vi visste att när vi öppnade upp affiliatesystemet för allmänheten kunde vi inte avsluta det. Visst, buggar händer som fixas, men om vi behövde byta en betalningsleverantör, kunde vi inte bara sätta våra affiliates på is medan vi fortsätter att samla in pengar som de skulle ha rätt till.

Flexibilitet var också en stor oro för oss. Vad händer om vi var tvungna att ändra de interna delarna av hur Prenumerationer hanterades (det hände faktiskt), skulle vi kunna hantera flera språk och valutor? Vad sägs om tillägg som vi utvecklat längs vägen som Redis, timmevisa säkerhetskopior, och så vidare. Kunde vi bygga en expanderbar instrumentpanel för våra användare?

Ur teknisk synvinkel visade det sig vara helt överflödigt att använda någon annans programvara. Eftersom vi har ett särskilt sätt att hantera prenumerationer via Stripe, behövde vi skriva vår egen logik för vad en hänvisning är och vad förändringsmekanismen är för uppgraderingar och nedgraderingar.

Medan jag är säker på att många lösningar har API:er, skulle att skriva koden för att skicka våra data till API vara 80% av arbetet. Varför inte göra de där ytterligare 20% och skapa vår egen UI, vilket vi är ganska skickliga på ändå.

Kostnader

Ett annat stort övervägande var prissättning. Det finns billiga produkter på marknaden men de dög inte på grund av funktions- eller flexibilitetsproblem. Andra tar hand om betalningar väl och har fler funktioner, men deras handelsavgifter blir ganska höga när de läggs ihop. Låt oss ta en titt på kostnaden för några av de mest populära. Obs! några av dessa kan kanske förhandlas ner lite baserat på försäljningsvolymen och andra faktorer.

• ShareASale: $550 engångs-nätverksavgift, $100 deposition, och en 20% transaktionsavgift på varje försäljning.
• CJ: $3,000 i nätverksavgift, $3,000 i deposition $500 årlig tillträdesavgift och 30% transaktionsavgift eller $0.30 på varje försäljning – beroende på vilket belopp som är högre.
• ClickBank: $49.95 aktiveringsavgift, $2.50 bearbetningsavgift per betalningsperiod och 7.5% transaktionsavgift + $1 vid varje försäljning.

Låt oss säga att vi tjänar $250,000 per år från affiliateförsäljning, här är hur avgifterna skulle bli (detta är efter engångsdeposition och nätverksåtkomstsavgifter). Förresten, vad är nätverksåtkomstavgifter? 🤔

• ShareASale: $50,000 i avgifter
• CJ: $75,000 i avgifter
• ClickBank: $27,000 i avgifter

Usch! Det är ganska mycket. Och det är innan du beräknar andra avgifter som vi redan betalar till vår betalningsprocessor Stripe. Vi såg också på andra affiliatesystem som Rakuten Marketing och Impact Radius, men kostnaderna var ännu högre.

Fördelen med att skapa vårt eget affiliatesystem är att vår största kostnad helt enkelt skulle vara utvecklingstid. Vi hade redan den fantastiska talangen i vårt team för att bygga allt. Men som du kan se finns det många rörliga delar och saker att tänka på när du väljer att skapa ditt eget eller köra på en tredjepartslösning.

Grunderna i hur vårt Affiliatesystem fungerar

Jag ska gå in på detaljer längre ner, men för att förstå hur vi började bygga produkten är det användbart att känna till det grundläggande flödet av data.

Inträdespunkten i systemet är en speciell länk som innehåller ett affiliate-ID. Vi kallar detta Kinsta affiliate-ID eller KAID (till exempel: https://kinsta.com?kaid=affiliateid)

De flesta andra affiliateverktyg är helt enkelt rent förvirrande när det gäller att veta vilken URL du ska använda och var du ska länka till. Så från början ville vi göra det till en enkel tvåstegsprocess.

Steg 1

Det första steget skulle vara att mata in destinationen på Kinstas webbplats. Detta kan vara var som helst, inte bara vår hemsida. Kanske vill de länka direkt till vår sida med planer (se nedan).

Steg 2

Det andra steget skulle vara att skapa länken åt dem så att de enkelt kan kopiera och klistra in detta var de vill. Och även att tillhandahålla den medföljande HTML-koden med länk-attributet rel=”sponsored” (vilket är mycket viktigt) för att följa Google’s riktlinjer för affiliate-länkar. Google rekommenderade tidigare att använda nofollow-attributet, vilket fortfarande är ett gångbart alternativ.

När vi upptäcker en besökare som använder en av dessa länkar ställer vi in en cookie som innehåller information om vem som hänvisade användaren. Vi värdesätter den ursprungliga referenten och erbjuder inte delade provisioner. Detta är rättvisare till affiliaten och leder till en konkurrens med kvalitet över kvantitet.

Stripe hanterar alla inköp, vi använder dess omfattande och (mestadels) väldokumenterade API för att skapa användare, prenumerationer, initiera betalningar och mer. Inköpsflödet sker på webbplatsen som i sin tur använder MyKinstas interna API för att initiera de processer vi behöver för att få användaren att registrera sig. Informationen om vem som hänvisade kunden registreras också i vårt system.

MVP (Börja bygga)

När du startar något nytt kan det vara klokt att bygga en MVP (minsta livskraftiga produkt) och börja marknadsföra direkt för att testa vattnet. Få feedback tidigt och lära oss av det. Anpassa, ändra och göra förbättringar. Detta är precis vad vi gjorde när vi först lanserade Kinsta, och det är så vi har bootstrappat från $0 till 7-siffrigt i intäkter.

Vi visste från starten att den mest utmanande delen av systemet skulle vara logiken som tar hand om spårning och beräkning av provisioner. Ursprungligen skrevs hela systemet i PHP och förlitade sig enbart på Stripe för att beräkna allt ad hoc.

Vi beräknade provisioner för en hänvisning genom att titta på hela Stripe-historien om den hänvisade prenumerationen och räkna ut hur mycket som ska betalas i engångs-provision och hur mycket återkommande som ska betalas. Faktorer som förfluten tid och typ av plan skulle påverka beräkningen.

Om WordPress-hänvisningen exempelvis skapades för två dagar sedan, fanns det naturligtvis ingen engångsprovision. Om WordPress-hänvisningen skapades för fyra månader sedan så var vi tvungna att tilldela engångsprovisionen (som ska betalas efter två månader) och två återkommande provisioner (som betalas en gång i månaden efter engångsprovisionen).

För att räkna ut det totala beloppet av provision som ska betalas för en månad gjorde vi ovanstående för alla hänvisningar från en viss affiliate. Detta visade sig vara mer beräkningsintensivt än vi ursprungligen trodde. Vi visste att vi skulle behöva göra en förändring, men vi hittade en bra kompromiss mellan funktionalitet och utvecklingstid.

Frontenden byggdes med hjälp av Flight PHP, ett PHP mikroramverk. Vi skapade några rutter, satte ihop några tabeller och grafer och så körde vi.

Ändra MVP (Anpassa och göra förbättringar)

Efter ungefär sju månader i privat beta och kanske sex månaders regelbunden användning behövde vi bygga om. Vår ursprungliga MVP byggdes helt enkelt inte för att kunna skalas. Vi behövde ändra hur vi hanterar prenumerationer på grund av våra nya tillägg och överskottssystem. Fram till denna tidpunkt hade en kund alltid en prenumeration. Vi behövde ändra det och tillåta flera prenumerationer per användare.

Eftersom våra kunder alltid hade en och endast en prenumeration kunde vi säkert säga att alla aktiva hänvisade prenumeration var lika med en hänvisad hostingplan. Med andra ord, prenumeration var vad vi räknade som hänvisningar. Vi behövde göra en fullständig förändring, som räknade våra Stripe-kunder som hänvisningar.

Dessutom började det icke-optimala sättet vi beräknade provisioner att bli mer och mer påtagligt. Det påverkade mestadels våra administratörer, men vi hade 1-2 affiliates som upplevde högre laddningstider medan vi beräknade alla deras provisioner varje gång de tittade på instrumentbrädan.

För att runda av saker ville vi flytta hela systemet till Node + React-territoriet för att få det att använda samma stack som MyKinsta. Detta skulle göra det möjligt för många fler av våra utvecklare att komma ombord om det behövdes och lättare att börja använda ett gemensamt designspråk.

Slutprodukten

När vi avslutade återuppbyggnaden fick vi ett mycket överlägset system som krävde mycket mindre hantering, hade många fler funktioner, automatiserade gemensamma affiliate-adminuppgifter och delade samma teknikstack som vår huvudprodukt, MyKinsta.

Stacken

Affiliatesystemet körs nu på Node på backenden och React på frontenden. Den använder GraphQL för våra förfrågningsbehov och Ant Design för designramen.

Det finns faktiskt fyra separata processer som körs samtidigt:

• Affiliate Backend: Detta är backenden av hela systemet. Den är helt avskild från den yttre världen; endast intern kommunikation kan nå den. Det är i grunden en ingångspunkt i databasen, allt det gör är att acceptera och svara på GraphQL-förfrågningar
• Affiliate-panelen: Detta är den användarvända sidan av affiliatesystemet. Det består av en massa React-komponenter som får sina uppgifter via GraphQL-förfrågningar från backenden
• Affiliate-admin: Detta är ett speciellt admin-gränssnitt dit administratörerna går för att titta på aggregerad statistik, hantera applikationer och utföra andra uppgifter
• Affiliate Sync: En uppsättning cron jobb som håller allt synkroniserat – vi kommer till denna del snart eftersom detta är en nyckelkomponent av systemet

Förbättringar av Data och Beräkningar

I den ursprungliga versionen av systemet beräknade vi allt ad hoc. Detta visade sig vara dataintensivt, och det är inte heller bra för att om vi ändrar något – som provisionsbeloppet – ändrar det antingen allt i efterhand eller så måste vi fylla koden med datumbaserade om-uttryck.

Det nya affiliate-systemet använder två mekanismer för att göra det mycket effektivare: ett bättre sätt att hämta data från Stripe och ett huvudbokssystem för att registrera händelser.

Händelsesystemet säkerställer att vad som än händer, stannar. Om en hänvisning ska belönas med en engångsprovision, registrerar vi den provisionen och bifogar den till hänvisningen. Vi markerar sedan den hänvisningen och tittar aldrig på enstaka provisioner igen. Samma mekanism gäller för återkommande provisioner. När en period har fått sin återkommande provision beräknad och registrerad kan vi ”glömma” den perioden.

Det innebär att beräkningar endast behöver göras under korta tidsperioder och aggregeringar av provisioner görs genom att helt enkelt summera några databasrader.

Den andra komponenten bygger på cron-jobb för att samla in data. Vi tar alla data från Stripe var 10:e minut och sparar den till en lokal databas som gör vissa ändringar för att underlätta ytterligare bearbetning.

Det krävs till exempel en inte obetydlig mängd kod för att ta reda på om en prenumerationsändrings-händelse innebär en värdplan. Vi kan beräkna denna ad hoc när vi behöver, men i stället för att göra det använder vi cron-jobbet för att lägga till en flagga till det sparade objektet. Eftersom vi hämtar 10 minuter av data tar hela processen kanske 100 millisekunder och gör ytterligare utvalda förfrågningar mycket effektivare.

Ett andra cron-jobb flyttar data till sin slutgiltiga plats, beräknar provisioner, skapar händelser och andra operationer.

Anledningen till att dessa görs separat är att den första operationen är superenkel men förlitar sig på Stripe medan den andra operationen är betydligt mer intensiv och komplex. Om vi introducerar en bugg i den andra operationen som gör att den misslyckas behöver vi inte synkronisera timmar/dagar/ veckor av Stripe-data; vi behöver bara köra den andra operationen igen.

Denna inställning ger många andra fördelar. Varje cron-jobb består i sin tur av flera olika komponenter som att få nya prenumerationer, godkänna pågående provisioner och så vidare. I framtiden kanske vi vill bryta ner våra cron-jobb ytterligare för att se till att vi kan fånga problem så tidigt som möjligt utan att påverka andra delar av systemet.

Efter att ha optimerat våra beräkningar och flyttat till en ny ram laddas vår affiliatepanel nu dubbelt så snabbt! 🚀

Affiliatesystemet och Programmet i Action

Inlägget skulle inte vara komplett utan att visa upp vårt affiliate-system och program i action. Här är bara några av de funktioner och fördelar vi erbjuder till alla våra affiliates på Kinsta.

1. Oslagbara Provisioner ( Registreringsbonus + Återkommande)

Vi arbetade länge och väl på vår provisions- och utbetalningsstruktur eftersom vi inser att detta förmodligen är en av de viktigaste faktorerna för affiliates. Faktum är att många bloggare och webbplatsägare vi hostar försörjer sig helt och hållet på sina affiliateinkomster. Vi är stolta över att nu erbjuda de högsta utbetalningarna i branschen! Och vi erbjuder provision oavsett vilka hostingtjänster som det hänvisas till.

Oavsett vilken hosting-plan för WordPress som någon hänvisar till så tillkommer det en engångsbonus, enligt följande:

• Starter plan ($50)
• Pro plan ($100)
• Business 1-4 ($150)
• Enterprise 1-2 ($500)

Affiliates får även en månatlig återkommande provision på 10 % för varje WordPress-hänvisning, utöver registreringsbonusen. Och för hänvisningar till applikationshosting och databashosting så erbjuder vi även 5 % månatliga återkommande provisioner. Men vänta, vi slutar inte där! De återkommande provisionerna är kumulativa, vilket gör det till ett av hosting-branschens bästa erbjudanden.

Nedan så har vi listat några av de många exempel som vi har på hur våra utbetalningar av WordPress-provisioner fungerar. Se fler exempel på utbetalningsscenarier i våra affiliatevillkor.

Exempel på WordPress-registreringsbonus

Exempel på WordPress återkommande provision

2. Spårning I Realtid

Vår affiliatepanel är olikt alla andra på marknaden! Du kan visa affiliatedata i nära realtid, sidvisningar, prenumerationer, djupgående plan-detaljer, och även gå in på enskilda hänvisningar och kontrollera alla betalningar från den hänvisningen (som visas nedan).

3. Högt Livslängdsvärde

En av de största fördelarna med att hänvisa människor till Kinsta är att vi har ett otroligt högt livstidsvärde för varje kund. Vårt kundbortfall är under 2%! Detta innebär att affiliates enkelt kan tjäna återkommande provisioner för den kundens livstid.

4. Månatliga Utbetalningar

Det finns inget behov för affiliates att oroa sig eller göra noteringar i sina kalendrar. Kinsta betalar alltid i tid och det skickas direkt till våra affiliates PayPal-konto varje månad.

5. Snabba Kampanjmaterial

Behöver banners för att främja Kinsta på en webbplats eller blogg? Oroa dig inte, vi har massor av dem! PR-banners och logotyper kan alla lätt nås direkt från affiliate-panelen.

6. Långt Konverteringsfönster

Folk är upptagna och kanske inte konverterar direkt. Människor gillar ofta att shoppa runt när det är dags att välja en ny molnhost. Det är därför vi ger våra affiliates 60-dagars spårningscookies för att säkerställa att de krediteras för försäljningen.

7. ITP 2.0 Ready

Kinstas affiliatesystem är ITP-2.0 redo! Intelligent Tracking Prevention 2.0 (ITP) är en ny inställning från Apple i Safari 11 och som i huvudsak begränsar åtkomsten som webbaserade spårningslösningar har till cookies i webbläsaren. Enligt Statcounter, räknat oktober 2018, har Safari fortfarande en 15%+ webbläsarmarknadsandel. Så denna förändring har stor inverkan på reklambranschen.

Men oroa dig inte. Kinstas affiliatesystem förlitar sig enbart på förstaparts-cookies utan studsande eller andra metoder för att kringgå ITP. Som ett resultat kommer alla hänvisningar att spåras och registreras på lämpligt sätt som de gjordes före ITP 2.0.

Vi byggde medvetet systemet utan att tillgripa ”ITP-säkra”-metoder av följande skäl:

1. Vi tror på ärlig, transparent spårning, och att samla in så lite data som möjligt.
2. Vi behöver inte spåra besökare genom flera webbplatser.
3. Vi förväntade oss att webbreglerna skulle bli strängare med tiden.

Du kan läsa mer om konsekvenserna av ITP 2.0.

8. Flerspråkig instrumentpanel – Finns på fem språk

Vår Kinsta affiliate-panel finns nu tillgänglig på åtta olika språk och fler kommer. För närvarande kan du välja följande:

• Engelska
• Tyska
• Franska
• Spanska
• Italienska
• Holländska
• Portugisiska
• Japanska

9. Att Hjälpa Affiliates att Lyckas

Förutom att bygga ett fantastiskt affiliatesystem och instrumentpanel, vill vi verkligen att affiliates ska lyckas. Det finns verkligen ingen gräns för hur mycket pengar de kan tjäna. Det är helt gratis för alla att gå med. Anmäl dig här.

Observera: Vi godkänner affiliate-konton manuellt, bara för att säkerställa att webbplatser följer våra affiliate-villkor.

Marknadsteamet på Kinsta, tillsammans med vår affiliate-manager, finns här för att hjälpa till. Vi ger gärna tips om affiliate-marknadsföring och affiliate-försäljningstips om sätt att ta kampanjer till nästa nivå. Faktum är att vi arbetar med att producera ytterligare innehåll på vår blogg som utformats speciellt för affiliatemarknadsförare, och sätt att öka resultatet.

Sammanfattning

Vår nuvarande implementering har visat sig vara mycket stabilare, ljusår snabbare och en bättre upplevelse för våra affiliates och administratörer. Det lade ner en solid grund baserad på vilken vi kan bygga en fantastisk produkt och program.

En stor fördel är att vi nu kan fokusera mer på användarvänliga förbättringar. Vi lade till fler diagram, URL-spårning och mer inom några månader efter lanseringen. Vi planerar att förbättra användarupplevelsen ytterligare och ge verktyg till våra affiliates som gör det möjligt för dem att tjäna mer.

Vi är inte i närheten av att vara klara här! 🤘

Funderar du på att bygga ditt eget affiliatesystem? Vi ska inte ljuga, det är mycket arbete, men väl värt tid och ansträngning. Vi har nu ett system hela vårt team är stolta över och som affiliates kan njuta av att använda.

Daniel Pataki

Hej, jag heter Daniel, jag är CTO här på Kinsta. Du kanske känner mig från Smashing Magazine, WPMU Dev, Tuts+ och andra WordPress/Utvecklings-tidningar. Bortsett från WordPress och PHP spenderar jag det mesta av min tid kring Node, React, GraphQL och andra teknologier i Javascript-utrymmet. När jag inte jobbar med att skapa den bästa hosting-lösningen i universum samlar jag på brädspel, spelar bordsfotboll på kontoret, reser eller spelar gitarr och sjunger i ett ganska dåligt band.

• Hemsida
• Twitter