It used to be so simple
Until relatively recently whenever I worked with a client who was designing a database to support their relationship management activity, or specifying a technology package to do so, there was one (at least) non-negotiable golden rule: Our thinking and our design starts with an Individual Person at its centre, not a household, not a company, not a product or brand – A person!. This rule was often challenged early in the thinking but I never had to waive the rule and am convinced that the basic principle helped prevent a number of poor decisions and wasted investment with clients trying to manage relationships with a semi-detached house or the third floor of an office building.
But now the world in on-line and social
Things do move on and I am now finding myself with an increasingly persuasive challenge to the golden rule and recognise that extreme care is needed, particularly in situations where the on-line, social world is central to a client’s relationship management. The dilemma is simple but profound: Should we store, record and manage at the Person level or at the level of the multiple Persona’s that they may choose to have in their on-line lives? To put it in database designer terms: Is a Persona (such as a Facebook name or Twitter handle) an attribute of a Person or is A Person an attribute of a Persona? At a more pragmatic level the decision is about whether we record and drive interactions by Person or by a chosen alias of which there could be many for each Person.
And it’s far too important to leave the decision to database designers
I have shared this conundrum with a number of very well qualified people and although each is very clear that there is only one answer they absolutely do not agree which it is. What they do agree on is that the decision is fundamental to the way that relationship management is delivered and just happens to be highlighted first at the database design stage. The frightening fact is the level of constraint that the wrong database design at such a fundamental level can have on plans for many years afterwards. So, even if the decision is flagged by the data design team it absolutely needs very serious and strategic level input from the business team, especially from those responsible for Marketing and any form of Relationship Management.
So, what are the factors to consider?
There clearly is no single answer for all situations but there are some factors that consistently have a major impact on driving the decision one way or another.
- Regulation. Decisions regarding People and Persona’s may be substantially made for you by the market regulation. For instance, alcoholic drinks companies are unlikely to risk promoting to a (claimed) “29 year old” Twitter handle when they know or even suspect that it is actually a 14 year old with an active imagination. So high regulation tends to suggest managing by Person.
- Value of ‘Orphan Personas’. If the organisation’s main interest in its relationship management is to drive behaviours that only relate to ‘real’ people then there is little point in having Personas on the database that cannot be linked back to a Person. But if the objectives major on areas such as advocacy and influence then a Persona can be just as influential, even if the Person behind it is not known.
- Balance of owned to earned media usage. If the organisation’s focus on relationship management is towards owned media and techniques such as email, SMS or direct mail then data on Personas is likely to just add richness to other communication and so the Person is the clear master. If there is a high usage of earned media then these interactions can still be valuable if they are with a Persona.
- Ability to link Personas. The nature of data available, whether owned or earned, can determine the feasibility of linking Personas to each other and into a Person. Unique identifiers such as email address make linking easy but are not always available. Implied linkages can be driven from, for example, comparisons between Foursquare log-ins and Facebook location.
- Brand or Portfolio. Where an organisation is heavily brand-based in its relationship management there is less of a driver to bring together multiple Personas. Those that manage across a portfolio of brands but still want to allow individuals to have different relationships with each brand should at least consider the Persona-centric approach even if they have the ability to link them together.
- Likelihood of material differences between Personas. It is always worth doing a reality check on whether the relationship needs or motivations of multiple Personas for a single Person are likely to be different or not for your consumers. Typically the less emotional / lifestyle products such as financial services do not have much variance, whereas a car buyer or mobile phone user may be quite different people in different social environments.
Is there a ‘right’ answer? Yes there is but it is going to be different in each situation. My conclusion is that we should still start with the Person at the centre and then work out what this prevents us from doing before being persuaded to move Persona’s to the centre of our database. For instance a consumer brand may only know Facebook Names and/or Twitter handles for 90% of the individuals with whom they are building relationships. This could be the persuasion need to move towards a persona-centric structure for owned data.
So, before signing off the mass of boxes and lines that the data design team put in front of you make sure you go right to the heart of the diagram and see what’s there. Person or Persona?
