Problemen met advertentie-assets komen vaak eerder door onduidelijk eigendom en verkeerde rechten dan door de advertentietactiek zelf. Inzicht in de Business Manager-hiërarchie, de reikwijdte van beperkingen en gescheiden eigendom van klantassets is belangrijker dan simpelweg meer accounts openen.
Wie langere tijd advertenties beheert, ontdekt dat het grootste probleem niet altijd is dat één account wordt geblokkeerd, maar dat je pas daarna merkt dat alle assets aan elkaar vastzaten. Om dit goed te ordenen, moet je eerst begrijpen wat er onder Business Manager (BM) hangt en hoe eigendom en toegangsrechten per onderdeel zijn geregeld.
Van een persoonlijk account naar de BM-laag
Een persoonlijk account is de enige toegangspoort tot de hele structuur. Je hebt er eerst een nodig om een BM te maken of een uitnodiging voor iemand anders zijn BM te accepteren. Als het persoonlijke account wordt uitgeschakeld, verlies je via die identiteit de toegang tot de structuur, maar de assets in de BM verdwijnen niet. Zolang de BM andere beheerders heeft, kunnen zij gewoon doorgaan.
Veel teams lopen precies hier tegen problemen aan: de BM heeft maar één beheerder en die persoon heeft hem toevallig met een secundair persoonlijk account aangemaakt.
Wie eigenaar is van de assets onder een BM
Een advertentieaccount is de feitelijke eenheid voor advertentieweergave en facturering en hoort bij een specifieke BM. Eén BM kan meerdere advertentieaccounts bevatten; hun budgetten en instellingen staan los van elkaar. Een advertentieaccount kan doorgaans niet rechtstreeks van de ene BM naar de andere worden verplaatst. Er moet een nieuw account worden gemaakt en de toegang moet opnieuw worden verleend.
Een Page is de publiek zichtbare identiteit achter advertenties. Die kan eigendom zijn van een BM of op naam van een persoon staan. Staat de Page op naam van een persoon, dan kan een advertentieaccount gebruiksrechten krijgen, maar het eigendom blijft bij die persoon.
Pixels en datasets zorgen voor conversietracking, terwijl doelgroepen en productcatalogi worden gebruikt voor targeting en advertentiemateriaal. Deze assettypen zijn eigendom van de BM en kunnen voor gedeeld gebruik aan verschillende advertentieaccounts binnen de BM worden toegewezen.
Eenvoudig samengevat: het persoonlijke account is de sleutel, de BM is de container en advertentieaccounts, Pages, pixels, doelgroepen en catalogi zijn de assets in die container. Wie eigenaar is van een asset bepaalt wie bij problemen bezwaar kan maken of de asset kan overdragen.
Wat er tegelijk kan uitvallen als er iets misgaat
Als een persoonlijk account wordt uitgeschakeld, is het meest directe gevolg dat niemand met die identiteit kan inloggen op de BM. Als de BM andere beheerders heeft, kan het bedrijf doorgaan terwijl voor het uitgeschakelde persoonlijke account apart bezwaar wordt gemaakt.
Als een advertentieaccount wordt geblokkeerd, worden de advertentieweergave en historische gegevens van dat account geraakt. De Page en pixel blijven doorgaans buiten schot. Je kunt een nieuw advertentieaccount maken, doorgaan met adverteren en de Page en pixel opnieuw toegang geven.
Als een Page wordt beperkt of geblokkeerd, worden alle advertenties die aan die Page zijn gekoppeld geraakt, ongeacht bij welk advertentieaccount ze horen. Dit is een typisch gevolg van assets door elkaar beheren.
Als een pixel of dataset problemen heeft, valt de conversiedata weg en werkt advertentieoptimalisatie minder goed. Met een nieuwe pixel kan de tracking doorgaan, maar historische data kan niet worden meegenomen, waardoor learning en attributie opnieuw moeten beginnen.
Als de BM zelf wordt beperkt, is de impact het grootst: advertentieaccounts, Pages en pixels eronder verliezen allemaal hun operationele toegang. In dat geval moet via de officiële procedure bezwaar worden gemaakt. De uitkomst hangt sterk af van hoe duidelijk het eigendom van de assets is en of er een geschiedenis van niet-conforme advertenties bestaat.
Waarom klantassets apart eigendom moeten blijven
Wanneer je advertenties voor een klant beheert, kan het op korte termijn handig lijken om de Page en pixel van de klant onder je eigen BM te hangen, maar op lange termijn ontstaat er risico. Krijgt jouw BM problemen, dan kunnen de assets van de klant worden meegesleept. Wanneer de samenwerking eindigt, kan het teruggeven van de assets bovendien vastlopen door de rechtenstructuur.
Een stabielere aanpak is dat de klant eigenaar van de assets blijft, de uitvoerende partij aan de BM van de klant wordt toegevoegd en alleen de voor het project benodigde rechten krijgt. Gebruik bij voorkeur één BM per klant, of groepeer assets ten minste per klant. Zo zijn de grenzen duidelijk en is ook helder wiens probleem wie raakt.
Rechten en loginomgevingen
Binnen een BM zijn er rollen voor beheerders en medewerkers, met verschillende rechtenniveaus. Het uitgangspunt is alleen toegang geven die echt nodig is: iemand die advertenties uitvoert heeft geen budgetrechten nodig, en iemand die met data werkt hoeft geen advertentiemateriaal te kunnen wijzigen. Controleer regelmatig de activiteitenlogboeken om fouten vroeg te ontdekken.
Aan de omgevingskant gaat het om wie waar inlogt. Plaats advertentieaccounts niet allemaal in dezelfde browseromgeving, vooral niet wanneer ze bij verschillende entiteiten horen. Wanneer meerdere mensen samen een groep accounts beheren, kun je met PurpleMark elk account een eigen, vaste browseromgeving geven en die op basis van rollen toewijzen. Zo blijft de koppeling tussen accounteigendom en loginomgeving beter overzichtelijk.
Pas wanneer de structuur op orde is, heeft het zin om over het beheren van meerdere accounts te praten.
