Affilierede Systemer Stinker, Så Vi Kørte Vores Egen

Lad os være helt ærlige; de fleste affilierede systemer på markedet er direkte forfærdelige. Enten er de forvirrende overbevist, klumpede og langsomme, eller de ser ud som om de blev designet tilbage i 90’erne. Eller værre, en blanding af alt ovenfor. Nogle kan have halvdelen af ​​de værktøjer, du har brug for, men så mangler andre vigtige funktioner, som dine affiliate marketingfolk ønsker. 😩

Siden vi har lanceret Kinsta, har det været vores mission, aldrig at skjule niget for kunderne. En standard vi opretholder er, at hvis det er noget, vi ikke selv ville bruge, så skal vi finde en bedre måde. Så som vi gjorde med vores MyKinsta dashboard, besluttede vi at bygge vores egne.

I dag diskuterer vi nogle af årsagerne til, at vi gik ned ad denne rute, både fra et forretnings- og udviklingsperspektiv, såvel som hvad vi endte med (fra MVP til slutproduktet).

• Hvorfor vi lavede vores egen
• Grundlæggende om, hvordan vores affilierede system fungerer
• MVP (Start Building)
• Ændring af MVP (Tilpasning og forbedring)
• Slutproduktet
• Affiliate-systemet og programmet i aktion

Hvorfor vi Byggede Vores Egen

Da vi begyndte at undersøge, hvad der skulle gøres for at gennemføre et affilieret system, indså vi hurtigt, at der ikke var nogen løsning for os. Her er de vigtigste grunde hvorfor:

• Det største problem var, at vores affilierede system skulle være tæt forbundet med vores planer og abonnementssystem, ikke hos en tredjepartsleverandør.
• Branding er meget vigtigt for os. Mens nogle affilierede systemer tilbyder hvidlabelløsninger, er de fleste halvbagte implementeringer og ikke altid fuldt gennemsigtige. At opbygge det selv vil give os fuld kontrol over design og branding uden at skulle bekymre os om hvidlabelløsninger.
• At stole på et tredjepartssystem forhindrer os i at tilføje nye funktioner hurtigt eller overhovedet. Det meste af vores brugerdefinerede MyKinsta dashboard er bygget helt ud af brugerfeedback, og derfor er det blevet et af de bedste WordPress site management værktøjer i branchen! Takket være vores fantastiske kunder. 👏  Vi vidste det øjeblik vi lancerede med en tredjepartsløsning, at feedback og anmodninger ville begynde at strømme ind, og vi ville ikke have evnen til at få dem til at ske.
• Evnen til at levere og opbygge brugerdefineret rapportering, ikke kun for vores partnere, men også for vores administratorer, var noget, vi ikke kunne leve uden. Vi elsker og har brug for data! Hvordan skal du ellers træffe strategiske beslutninger? At trække rapporteringsdataene måtte også ske fra vores komplekse planer og abonnementssystem.

Ved at grave lidt mere ind i dette, vidste vi, at når først vi har åbnet affilierede systemer til offentligheden, kunne vi ikke stoppe det. Selvfølgelig kan der opstå små problemer, men hvis vi skulle skifte betalingsudbyder, kunne vi ikke bare sætte vores datterselskaber på hold, mens vi fortsætter med at samle penge, som de ville have ret til.

Også fleksibilitet var en stor bekymring. Hvad hvis vi skulle ændre den interne lside af, hvordan abonnementerne blev håndteret (dette faktisk endte med at ske), ville vi kunne håndtere flere sprog og valutaer? Hvad med tilføjelser, som vi udviklede undervejs som Redis, timelige backups, og så videre. Kunne vi opbygge et udvideligt dashboard til vores brugere?

Fra et teknisk synspunkt viste det sig at være fuldstændigt overflødigt at bruge andres software. Da vi har en særlig måde at håndtere abonnementer på via Stripe, måtte vi skrive vores egen logik for, hvad en henvisning er, og hvad ændringsmekanismen er for opgraderinger og nedgraderinger.

Selvom jeg er sikker på, at mange løsninger har API’er, vil skrivningen af ​​koden til at sende vores data til API’en være 80% af arbejdet. Hvorfor ikke indsætte yderligere 20% og opret vores eget brugerinterface, som vi alligevel er dygtige til.

Omkostninger involveret

En anden stor bekymring var prissætning. Der er billige produkter på markedet, men de har ikke lavet udskæringen på grund af funktionalitet eller fleksibilitetsproblemer. Andre nyder godt af betalingerne og har flere funktioner, men deres handelsafgifter opkræves hurtigt. Lad os tage et kig på omkostningerne ved nogle af de mest populære. Bemærk: nogle af disse kunne måske forhandles lidt ned baseret på mængden af ​​salg og andre faktorer.

• ShareASale: 550$ engangs netværk gebyr, 100$ depositum og en 20% transaktionsgebyr på hvert salg.
• CJ: 3.000$ netværk gebyr, 3.000$ depositum, 500$ årligt adgangsgebyr og 30% transaktionsgebyr eller 0,30$ på hvert salg – alt efter hvilket beløb der er større.
• ClickBank: 49,95$ aktiveringsafgift, 2,50$ betalingsperiode forarbejdningsgebyr og 7,5% transaktionsgebyr + 1$ på hvert salg.

Lad os sige, at vi tjener 250.000$ om året fra affilieret salg, her er hvad gebyrerne ville komme ud for (dette er efter et engangsindskud og netværksadgangsgebyrer). Forresten, hvad er netværksadgangsgebyrer? 🤔

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

Yikes! Det er meget. Og det er før du beregner i andre gebyrer, som vi allerede betaler til vores betalingsprocessor Stripe. Vi kiggede også på andre tilknyttede systemer som Rakuten Marketing og Impact Radius, men omkostningerne var endnu højere.

Fordelen med at lave vores eget affilierede system er, at vores største omkostninger simpelthen ville være udviklingstid. Vi havde allerede det fantastiske talent internt for at bygge alt. Men som du kan se, er der mange bevægelige dele og ting at overveje, når du vælger at køre din egen eller gå med en tredjepartsløsning.

Grundlæggende om, Hvordan Vores Affilierede System Fungerer

Jeg går ind i detaljer længere nede, men for at forstå, hvordan vi begyndte at bygge produktet, er det nyttigt at kende den grundlæggende datastrøm.

Indgangspunktet i systemet er et specielt link, der indeholder et tilknyttet ID. Vi kalder dette Kinsta-tilknyttet ID eller KAID som forkortelse (eksempel: https://kinsta.com?kaid=affiliateid)

De fleste andre tilknyttede værktøjer er simpelthen ret forvirrende, når det kommer til at skulle vide, hvilken webadresse du skal bruge, og hvor du skal linke til den. Så fra begyndelsen ønskede vi at gøre det til en enkel to-trins proces.

Trin 1

Det første skridt ville være at indtaste destinationen på Kinsta hjemmeside. Dette kunne være overalt, ikke kun vores hjemmeside. Måske ønsker de at linke direkte til vores planlægningsside (som vist nedenfor).

Trin 2

Det andet trin ville være at generere linket til dem, så de nemt kan kopiere og indsætte dette, hvor de vil. Og også at give den medfølgende HTML med rel=”sponsored” link-attributten (hvilket er meget vigtigt) for at overholde Googles retningslinjer for affiliate links. Google anbefalede tidligere at bruge nofollow-attributten, som stadig er en levedygtig mulighed.

Når vi registrerer en besøgende ved hjælp af sådan et af disse links, sætter vi en cookie, der indeholder oplysninger om, hvem der henviste brugeren. Vi værdsætter den oprindelige henvisning og tilbyder ikke delte provisioner. Dette er retfærdigere for affiliate og fører til en konkurrence af kvalitet over kvantitet.

Stripe håndterer alle køb, vi bruger dens omfattende og (for det meste) veldokumenterede API til at oprette brugere, abonnementer, initiativer og mere. Købstrømmen sker på hjemmesiden, som igen bruger MyKinstas interne API til at igangsætte de processer, vi har brug for for at få brugeren tilmeldt. Oplysningerne om, hvem der henviste kunden, registreres også i vores system.

MVP (Start Building)

Når du lancerer noget nyt, kan det være klogt at opbygge en MVP (minimum levedygtigt produkt) og starte marketing med det samme for at teste farvandet. Få feedback tidligt og lær af det. Tilpas, ændre og foretag forbedringer. Det er præcis det, vi gjorde, da vi først lancerede Kinsta, og hvordan vi har bootstrapped fra 0$ til 7-tal i omsætning.

Vi vidste, at den mest udfordrende del af systemet ville være logikken, der tager sig af sporing og beregning af provisioner. Oprindeligt blev hele systemet skrevet i PHP og stod udelukkende på Stripe for at beregne alt ad hoc.

Den måde, vi beregnede provisioner på for en henvisning, var at se på hele Stripe-historien for det omtalte abonnement og finde ud af, hvor meget engangskommission skyldes, og hvor meget tilbagevenden skyldes. Faktorer som forældet tid og plantype vil påvirke beregningen.

For eksempel, hvis WordPress-henvisningen blev oprettet for to dage siden, var der naturligvis ingen engangskommission. Hvis WordPress-henvisningen blev oprettet for fire måneder siden, var vi nødt til at tildele engangskommissionen (som forfalder efter to måneder) og to tilbagevendende provisioner (forfalder en gang om måneden efter engangskommissionen).

For at få det samlede beløb af provision, der skal betales for en måned, gjorde vi ovenstående for alle henvisninger fra en bestemt tilknyttet. Dette viste sig at være mere beregningsintensive end vi oprindeligt troede. Vi vidste, at vi skulle lave en forandring, men vi fandt et godt kompromis mellem funktionalitet og udviklingstid.

Front-end blev bygget ved hjælp af Flight PHP, en PHP mikro-ramme. Vi skabte nogle ruter, sammensatte nogle tabeller og grafer og så kørte vi.

Ændring af MVP (Tilpasning og forbedring)

Efter ca. syv måneder i privat beta og måske seks måneders regelmæssig drift måtte vi genopbygge. Vores oprindelige MVP blev ikke bygget til at skalere. En ændring måtte foretages i den måde, vi håndterer abonnement på grund af vores nye add-ons og overage systemer. Indtil dette tidspunkt havde en kunde altid et abonnement. Vi havde brug for at ændre det og tillade flere abonnementer pr. bruger.

Da vores kunder altid havde ét eneste abonnement, kunne vi med sikkerhed sige, at ethvert aktivt henvist abonnement var lig med en henvist hostingplan. Med andre ord var abonnementer, hvad vi betragtede som henvisninger. Vi var nødt til at foretage en komplet renovering, som anser vores Stripe-kunder for at være henvisninger.

Desuden begyndte den suboptimale måde, vi beregnede opgaver på, at vise sit grimme hoved. Det ramte hovedsageligt vores admins, men vi havde 1-2 datterselskaber, der oplevede højere belastningstider, mens vi regnede med alle deres provisioner hver gang de betragtede instrumentbrættet.

For at afrunde tingene ønskede vi at flytte hele systemet ind i Node + React-området for at gøre det muligt at bruge samme stak som MyKinsta. Dette ville gøre det muligt for meget flere af vores udviklere at komme om bord, hvis det er nødvendigt, og at begynde at bruge et fælles designsprog lettere.

Slutproduktet

Da vi var færdige med genopbygningen, blev vi overladt til et langt bedre system, som krævede meget mindre ledelse, havde mange flere funktioner, automatiserede fælles affilierede admin opgaver og delte samme teknologi stak som vores hovedprodukt, MyKinsta.

Stakken

Det tilknyttede system kører nu på Node på backend og React på forsiden. Det udnytter GraphQL til vores forespørgselsbehov og Ant Design for designrammen.

Der er faktisk fire separate processer, der kører på samme tid:

• Affiliate Backend: Dette er backend for hele systemet. Den er helt lukket af den eksterne verden; Kun intern kommunikation kan nå det. Det er dybest set et indgangspunkt i databasen, alt det gør er at acceptere og svare på GraphQL-forespørgsler
• Affiliate Dashboard: Dette er den bruger-side af affiliate-systemet. Den består af en flok React-komponenter, der får deres data via GraphQL-forespørgsler fra backend
• Affiliate Admin: Dette er en speciel admin-grænseflade, hvor administratorerne går til at se på aggregerede statistikker, administrere applikationer og udføre andre opgaver
• Affiliate Sync: Et sæt cron-job, der holder alt i synkronisering – vi kommer snart til denne del, da dette er kødet og knoglerne i systemet

Forbedringer af data og beregninger

I den oprindelige version af systemet har vi beregnet alt ad hoc. Dette viste sig at være datintensive, men det er heller ikke godt, fordi hvis vi ændrer noget – ligesom størrelsen af ​​det betalte beløb – ændres det alt i tilbageblik, eller vi skal smide koden med datobaseret if erklæringer ud.

Det nye affilierede system bruger to mekanismer til at gøre det meget mere effektivt: en bedre måde at tage fat på data fra Stripe og et ledger system til at optage begivenheder.

Arrangementet sikrer, at det uanset hvad der sker, forbliver. Hvis en henvisning skyldes en engangsprovision, registrerer vi denne provision og vedlægger den til henvisningen. Vi markerer så den henvisning og ser aldrig på engangsprovisioner igen. Den samme mekanisme gælder for tilbagevendende provisioner. Når en periode har haft sin tilbagevendende provision beregnet og registreret, “glemmer vi” den periode.

Det betyder, at beregninger kun skal foretages i korte perioder, og aggregater af provisioner foretages ved blot at opsummere nogle databaseresultater.

Den anden komponent er afhængig af cron-job for at indsamle data. Vi henter alle data fra Stripe hvert 10. minut og gemmer den til en lokal database, der gør nogle ændringer for, at gøre yderligere behandling lettere.

For eksempel tager det en ubetydelig mængde kode for at finde ud af, om et abonnementsændringsbegivenhed indebærer en hostingplan. Vi kan beregne dette ad hoc, når vi skal, men i stedet for at gøre det bruger vi cron jobbet til at tilføje et flag til det gemte objekt. Da vi tager 10 minutter data, tager hele processen måske 100 millisekunder og gør yderligere udvalgte forespørgsler meget mere effektive.

Et andet cron job blandes dataene til dets endelige sted, beregning af provisioner, oprettelse af begivenheder og andre operationer.

Årsagen til at disse er lavet særskilt er, at den første operation er super-simpel, men afhænger af Stripe, mens den anden operation er betydeligt mere intensiv og kompleks. Hvis vi introducerer en fejl i den anden operation, der gør det svigtet, behøver vi ikke at genindstille timer/dage/uger med Stripe data; vi skal bare genbruge den anden operation.

Denne opsætning giver mange andre fordele, som hvert cron-job er i sin tur består af flere forskellige komponenter som at få nye abonnementer, godkende ventende provisioner og så videre. I fremtiden vil vi måske nedbryde vores cron job yderligere for at sikre, at vi kan fange problemer så tidligt som muligt uden at påvirke andre dele af systemet.

Efter optimering af vores beregninger og flytning til en ny ramme loader vores tilknyttede dashboard dobbelt så hurtigt nu! 🚀

Affiliate-systemet og programmet i aktion

Stillingen ville ikke være komplet uden at vise vores affilierede system og program i aktion. Her er blot nogle af de funktioner og fordele, vi tilbyder til alle partnere hos Kinsta.

1. Uovervindelige Provisioner (Tilmeld Bonus + Tilbagevendende)

Vi arbejdede længe og hårdt på vores kommission og udbetalingsstruktur, da vi indser, at dette sandsynligvis er en af de vigtigste faktorer for datterselskaber. Faktisk tjener mange bloggere og websejere, som vi er vært for, hele deres levevej fra affilierede indkomster. Vi er stolte over at tilbyde de højeste udbetalinger i branchen! Og vi tilbyder provision, uanset hvilke hostingtjenester der henvises til.

For hver KinstaWordPress hostingplan, som nogen henviser til, får de en engangs-tilmeldingsbonus som følger:

• Starterplan (50$)
• Pro plan (100$)
• Forretning 1-4 (150$)
• Enterprise 1-2 (500$)

Tilknyttede selskaber får også en 10% månedlig tilbagevendende kommission for hver WordPress-henvisning, oven i tilmeldingsbonussen. Og for henvisninger til applikationshosting og databasehosting tilbyder vi også 5% månedlige tilbagevendende provisioner. Men vent, vi stopper ikke der! De tilbagevendende provisioner er kumulative, hvilket gør det til et af hostingbranchens bedste tilbud.

Nedenfor er blot nogle få af de mange eksempler, vi har på, hvordan vores WordPress kommissionsudbetalinger fungerer. Se flere eksempler på udbetalingsscenarier i vores affilierede vilkår.

Eksempel på WordPress tilmeldingsbonus

Eksempel på WordPress tilbagevendende kommission

2. Sporing i realtid

Vores tilknyttede dashboard er ikke som alle andre på markedet! Du kan få vist tilknyttede data i nærheden af realtid, sidevisninger, abonnementer, detaljerede planoplysninger og endda drill down til individuelle henvisninger og kontrollere alle betalinger fra den ene henvisning (som vist nedenfor).

3. Høj levetidsværdi

En af de største fordele ved at henvise folk til Kinsta er, at vi har en utrolig høj levetid værdi for hver klient. Vores churn rate er under 2%! Det betyder, at datterselskaber nemt kan tjene tilbagevendende provisioner for denne kundes levetid.

4. Månedlige udbetalinger

Der er ingen grund til, at filialer skal bekymre sig eller markere i deres kalendere. Kinsta betaler altid til tiden, og den sendes til højre for affiliates PayPal-kontoen hver måned.

5. Quick Promo Materials

Har du brug for bannere til at fremme Kinsta på et websted eller en blog? Bare rolig, vi har mange af dem! De salgsfremmen de bannere og logoer kan alle nemt nås lige fra det tilknyttede dashboard.

6. Lang konverteringsvindue

Folk er optaget og kan ikke konvertere med det samme. Mange gange kan folk lide at shoppe rundt, når det bliver tid til at vælge en ny cloud-host. Derfor tilbyder vores datterselskaber 60-dages tracking cookies for at sikre, at de bliver krediteret for salget.

7. ITP 2.0 klar

Kinsta affiliate-systemet er ITP 2.0 klar! Intelligent Tracking Prevention 2.0 (ITP) er en ny indstilling fra Apple i Safari 11 og nyere, som i det væsentlige begrænser den adgang, webbaserede sporingsløsninger har til cookies i browseren. Ifølge en nylig undersøgelse har Safari i oktober 2020 stadig omkring 8% af webbrowserens markedsandel. Så denne ændring har stor indflydelse på reklamebranchen.

Men ikke for at bekymre dig. Kinsta-affilieringssystemet er udelukkende afhængigt af cookies fra første part uden at hoppe eller andre metoder til at sidestille ITP. Som følge heraf vil alle henvisninger spores og registreres hensigtsmæssigt, da de har været før ITP 2.0.

Vi har bevidst bygget systemet uden at anvende “ITP-proof” metoder af følgende årsager:

1. Vi tror på ærlig, gennemsigtig sporing og samler så lidt data som muligt.
2. Vi behøver ikke at spore besøgende gennem flere websteder.
3. Vi forventede, at reglerne på nettet blev strengere med tiden.

Du kan læse mere om forgreningerne af ITP 2.0.

8. Flersproget Dashboard – Fås i fem sprog

Vores Kinsta affiliate dashboard er nu tilgængeligt på otte forskellige sprog, og flere er på vej. I øjeblikket kan du vælge følgende:

• engelsk
• tysk
• fransk
• spansk
• italiensk
• hollandske
• portugisisk
• japansk

9. Hjælper Affiliates Succeed

Udover at opbygge et fantastisk affilieret system og dashboard, ønsker vi virkelig, at datterselskaber skal lykkes. Der er virkelig ingen grænse for hvad de penge, de kan gøre. Det er helt gratis for nogen at deltage. Tilmeld dig her.

Bemærk: Vi godkender godkendte tilknyttede konti manuelt, bare for at sikre, at websteder overholder vores affiliate vilkår.

Marketingteamet hos Kinsta er sammen med vores affiliate manager her for at hjælpe. Vi giver gerne tips til affiliate marketing og affiliate salgstips om måder at tage kampagner til det næste niveau. Faktisk arbejder vi på at producere yderligere indhold på vores blog, der er designet specifikt til affiliate marketing, og måder at øge indtjeningen på.

Resumé

Vores nuværende implementering har vist sig at være meget mere stabil, lysår hurtigere og en bedre oplevelse for vores partnere og admins. Det lagde et solidt fundament ud, på grundlag af hvilket vi kan bygge et fantastisk produkt og program.

En stor fordel er, at vi nu kan fokusere mere på forbedringer af brugeren. Vi har tilføjet flere diagrammer, sporing af webadresser og mere i løbet af nogle måneder efter udgivelsen. Vi planlægger at forbedre brugeroplevelsen endnu mere og give værktøjer til vores partnere, som gør det muligt for dem at tjene mere.

Vi er ikke tæt på at være færdige 🤘

Tænker du på at opbygge dit eget affilierede system? Vi vil ikke lyve, det er meget arbejde, men det er værd at bruge tid og kræfter på. Vi har nu et system, som hele vores team er stolte af, og datterselskaber nyder at bruge.

Daniel Pataki

Hej, jeg hedder Daniel, jeg er CTO her hos Kinsta. Du kender mig måske fra Smashing Magazine, WPMU Dev, Tuts+ og andre WordPress/Development-magasiner. Bortset fra WordPress og PHP bruger jeg det meste af min tid omkring Node, React, GraphQL og andre teknologier i Javascript-rummet. Når jeg ikke arbejder på at lave den bedste hostingløsning i universet, samler jeg på brætspil, spiller bordfodbold på kontoret, rejser eller spiller guitar og synger i et ret dårligt band.

• Hjemmeside
• Twitter