Een Enkele Bron Van Waarheid Bouwen Voor Revenue-Attributie

Vraag drie mensen in een revenue-organisatie hoeveel deals er vorig kwartaal zijn gesloten en u krijgt waarschijnlijk drie getallen. Marketing haalt het uit het automatiseringsplatform, sales uit het CRM, finance uit facturatie, en elk van hen kan zijn getal twintig minuten lang verdedigen. We hebben in die meeting gezeten. Niemand heeft precies ongelijk. Maar zodra de basisaantallen het oneens zijn, erft elk attributiemodel dat erbovenop wordt gebouwd die onenigheid, en geen enkele modelverfijning repareert een analyse die begint bij tegenstrijdige feiten.

Een enkele bron van waarheid voor attributie is de saaie infrastructuur die al het andere geloofwaardig maakt. Het is geen dashboard, en het is niet de spreadsheet die iemand op de laatste vrijdag van de maand handmatig reconcilieert. Het is een beheerde datalaag waar identiteit, events en revenue elke keer op dezelfde manier worden samengevoegd. Dit is wat het bouwen van zo'n laag daadwerkelijk vergt.

Waarom de cijfers uit elkaar drijven

Fragmentatie is geen teken dat iemand slecht werk heeft geleverd. Het is wat er gebeurt met elke stack die groeit. Elke tool die u aanschaft, is het systeem van record voor zijn eigen plakje van de werkelijkheid, met zijn eigen identifiers, zijn eigen timestamps, en zijn eigen definities van wat iets is.

• Het CRM kent accounts en opportunities, maar de bedrijfsrecords zijn verouderd of gedupliceerd.
• Het marketingplatform kent contacten en engagement, en kan een persoon vaak niet aan het juiste account koppelen.
• De productdatabase kent gebruik, gekoppeld aan een interne gebruikers-ID die nergens op de salesside naar mapt.
• Facturatie weet wat daadwerkelijk is gefactureerd, op een accounthiërarchie die niet overeenkomt met die van het CRM.

Elk van deze is intern consistent en incompatibel met de anderen. Het is dezelfde conditie achter waarom uw revenue-stack fragmenteert. Attributie is gewoon waar de pijn het hardst klinkt, omdat attributie over al deze systemen tegelijk moet samenvoegen.

Drie joins dragen het geheel

Een werkende SSOT komt neer op het oplossen van drie identiteitsproblemen. Los ze goed op en het meeste stroomafwaartse analysewerk wordt behapbaar. Los ze verkeerd op en elk model raakt stilzwijgend gecorrumpeerd, en meestal komt u er pas achter als iemand hogerop een scherpe vraag stelt.

Contact-naar-account is de eerste. Elke persoon moet naar het juiste bedrijf herleiden, over e-maildomeinen, dochterondernemingen, en het persoonlijke Gmail-adres dat een VP gebruikte om zich voor een webinar in te schrijven. Zonder dat kunt u niet zien dat zes mensen van één account u allemaal evalueren, wat betekent dat buying-committee-analyse van tafel is.

Accounthiërarchie is de tweede. Ouders, kinderen, overgenomen merken, regionale divisies. Als deze niet consistent oprollen, ziet een globaal account eruit als een dozijn ongerelateerde kleine accounts en raakt zijn revenue verspreid over records die niemand met elkaar verbindt.

Contactmoment-naar-revenue is de derde. Elke marketing- en salesinteractie moet aansluiten bij de opportunity waar hij bij hoort en, uiteindelijk, bij de revenue die is gefactureerd, met één definitie van wat als opportunity telt en wanneer die begint.

Hier zit het eigenlijke engineeringwerk. Fuzzy matching, deterministische sleutels, verrijking, dedup. Alles dient één doel: een stabiele, canonieke identiteit voor elk account en elke persoon waar elk systeem het over eens is.

Governance verslaat slimme SQL

Het instinct is dit als een technisch project te behandelen. Alles het warehouse in pipen, wat modellen schrijven, klaar. Maar in onze ervaring is het loodgieterswerk zelden wat faalt. De definities zijn het. Als marketing een MQL op de ene manier telt en sales een gekwalificeerde opportunity op een andere, verplaatst het unificeren van de opslag alleen het argument naar een andere kamer.

Dus een duurzame SSOT heeft governance nodig naast de engineering. Dat betekent één afgesproken betekenis voor account, opportunity, stage en revenue, opgeschreven en eigendom van iemand. Het betekent beslissen welk systeem gezaghebbend is voor welk feit (facturatie voor revenue, het CRM voor stage) en niet langer elke systeemversie als even geldig behandelen. Het betekent dat afnemers kunnen zien hoe vers elk veld is en waar het vandaan komt, omdat attributie gebouwd op de snapshot van vorige week zal misleiden. En het betekent brede toegang tot de uniforme laag gekoppeld aan duidelijk eigenaarschap, zodat de definities niet binnen een kwartaal weer uit elkaar drijven.

Dit is ook de discipline die de cijfers de confrontatie met finance laat overleven, wat het hele onderwerp is van waarom uw CFO uw attributie wantrouwt. De CFO wil geen mooiere grafiek. Ze willen weten dat het getal aansluit bij het grootboek.

Genoeg architectuur, niet te veel

U heeft geen tweejarig dataplatform-initiatief nodig om te beginnen, maar u heeft wel de juiste vorm nodig. De pragmatische versie is gelaagd: ruwe ingestie vanuit elke bron, een identiteitsresolutiestap die canonieke sleutels toewijst, een gemodelleerde laag waar events aansluiten bij accounts en revenue onder de beheerde definities, en een serveerlaag die zowel rapportage als activering voedt. Het volledige blauwdruk staat in de referentiearchitectuur voor een revenue-platform.

Twee dingen houden het tegen tegen opblazen.

Modelleer voor activering én rapportage. Een SSOT die alleen dashboards voedt, is half gebouwd. Diezelfde uniforme laag zou ook live signalen en next best actions naar reps moeten voeden, wat de premisse is van verspreide data omzetten in next best actions. Als de enige afnemer een wekelijks rapport is, vervalt de laag omdat niemand er dagelijks van afhangt.

En koop de identiteitsresolutie. Contact-naar-account-matching op schaal is een genoeg opgelost probleem dat het zelf bouwen zelden de engineers waard is. Orchestratieplatforms zoals Revnewo leveren deze unificatielaag native, zodat de tijd van het team naar definities en actie gaat in plaats van loodgieterswerk.

Belangrijkste inzichten

• Als de basisaantallen het oneens zijn, is het attributiemodel al fout. Repareer het fundament voordat u over weging discussieert.
• Fragmentatie is normaal. Elke tool is een goed systeem van record voor zijn eigen plakje en een slecht voor de rest.
• Drie joins doen het meeste werk: contact naar account, accounthiërarchie, en contactmoment naar revenue.
• Definities en eigenaarschap doen er meer toe dan modelleervernuft. Uniforme opslag met tegenstrijdige definities verplaatst alleen het geschil.
• Bouw de laag zodat hij zowel actie als rapporten voedt, en herbouw identiteitsresolutie niet vanaf nul.

Niets hiervan is het spannende deel van attributie. Het is het deel waar al het andere op staat. Als u tegenstrijdige cijfers reconcilieert voor elke analyse, is een revenue-orchestratieplatform dat identiteit en revenue-unificatie afhandelt hoe u daarmee stopt.