Beauty Profile Data Model: How to Store, Version and Refresh It

Most teams integrate a skin and hair analysis API, see the JSON come back, and then face the real question: where does this live? A beauty profile that exists only inside one session is a nice demo. A beauty profile that is stored, versioned and refreshed becomes an asset your CRM, your product pages and your advisor can all use. This article lays out a practical beauty profile data model for beauty brands, retailers and e-commerces — the fields, the metadata around them, and the rules that keep the whole thing trustworthy.

What a beauty profile actually contains

MaIA Scan takes a selfie and returns a structured profile: skin tone and undertone, skin type and visible condition, hair attributes, and a confidence value per field. It describes what is visible in a photo. It does not diagnose anything and does not replace a professional — that distinction matters when you write field names, because a column called skin_condition_observed sets very different expectations internally than one called diagnosis.

So the raw material is: a set of attributes, each with a confidence, produced at a moment in time from one image under one lighting condition. Your data model has to carry all four of those things, not just the first.

The beauty profile data model: fields, confidence and provenance

Think of the profile as an event, not a property. A customer does not "have" a skin tone in your database; your system observed one, on a given date, from a given photo, with a given confidence. Modelling it as an event solves most of the problems that appear six months later.

Store the confidence, not just the value

The most common integration mistake is flattening the response: keeping undertone = "warm" and discarding the confidence that came with it. Once the number is gone, every downstream system treats a strong read and a weak read identically, and your recommendation logic has no way to be careful.

Keep the confidence next to each value, and decide thresholds per use case rather than globally. A shade shortlist on a product page can tolerate a moderate read because the customer will see the result and correct it. An automated CRM segment that triggers a campaign should demand more, because nobody is in the loop to catch a bad call. Low confidence is not a failure; it is a signal to ask for a better photo or to widen the shortlist.

Keep provenance and timestamps

Every stored profile should carry: when it was captured, which channel it came from (product page, WhatsApp flow, in-store tablet, loyalty onboarding), which version of the analysis produced it, and whether the customer confirmed or corrected any field afterwards. That last one is gold. A customer who manually changes their shade after seeing the result is telling you something your model cannot see, and a source: user_confirmed flag lets you prioritise their input over any new automated read.

Separate observed attributes from derived decisions

Resist the urge to store "recommended foundation SKU" inside the profile. Catalogs change, stock moves, formulas get discontinued. Keep observed attributes in one layer and recommendations in another, generated at read time against the current catalog. This is how MaIA Beauty Advisor works in practice: it reads the profile and resolves it against the brand's live catalog, so the same stored profile yields a valid answer this season and next.

Where the profile lives: session, CRM, or both

There are three reasonable architectures, and the right one depends on what you want to do with the data.

Session only. The profile exists for the duration of the visit, powers a shade shortlist or a try-on, and is discarded. Lightest possible footprint, simplest consent conversation, zero retention questions. The cost is that the customer starts from zero every time and you learn nothing at the audience level.

Stored against an identified customer. The profile is written to your CRM or customer data platform, keyed to an account. Now you can segment, personalise email and WhatsApp, pre-fill the next visit and measure whether profiled customers behave differently from the rest. This requires explicit consent and a retention policy, and it is where most of the long-term value sits.

Hybrid. Analyse in session, offer storage as a benefit — "save your profile so we remember your shade" — and only persist for those who accept. In Brazil, under the LGPD, treat biometric-adjacent data with the care it deserves: clear purpose, explicit opt-in, an easy way to delete.

What to do with the photo

The safest default is: do not keep it. Store the derived attributes, not the image. If you have a genuine reason to retain photos — a before-and-after feature, for example — make that a separate, explicitly consented decision with its own retention window, not a side effect of running an analysis.

Refreshing the profile: when to re-scan

Attributes drift. Skin condition changes with season and routine; hair changes with colouring and cuts; tone shifts with sun exposure. A profile captured in January is not wrong in July, but it is older.

A workable rule: attach an age to every profile and let each use case decide its own tolerance. A loyalty dashboard can show a profile from last year with a "refresh" prompt. A foundation shade recommendation benefits from something recent. Trigger a re-scan naturally — at the start of a new season, before a replenishment campaign, or when the customer returns a product for shade reasons — rather than nagging on a fixed calendar.

When you re-scan, version rather than overwrite. Keeping the history lets you see change over time, and it protects you from a single poorly lit photo wiping out a good read.

Putting the profile to work

Once the model is clean, the applications stack easily: a shade shortlist on the product page, a segment in your CRM, a starting point for a conversation on WhatsApp, a personalised result page after a quiz. The profile is the shared vocabulary between all of them — which is exactly why it deserves a deliberate schema instead of an ad-hoc JSON blob in a notes field.

Ready to design yours? Create an account, get an API key and inspect a real response in the MaIA API documentation, or talk to our team about mapping the profile to your catalog and CRM.