SitecoreAI creates a profile automatically for every visitor. Everything below that first line is populated from captured events. Sitecore specifically calls out VIEW and IDENTITY as the events that drive what the profile can show.

The step developers usually misunderstand is the arrow from Sessions to Events. If an event isn't sent, nothing downstream of it exists. No affinity score, no identity, no audience match.

Step 1: Know the three profile types

You'll see three states while testing:

• Visitor: created automatically for a new, anonymous visitor.
• Identified: holds identifying information captured through an IDENTITY event, and can be merged by identity resolution.
• Retired: a duplicate that has been merged into another profile and no longer appears as active in the Profiles UI.

Retired profiles catch testers off guard. You browse on your phone, sign in on your laptop, and the phone profile "vanishes." That's identity resolution merging it, which is exactly what you wanted.

Step 2: Open Profiles

1. Open SitecoreAI.
2. Go to Performance.
3. Select Profiles.

The page lists recent visitor profiles and supports filtering and search.

Understand the display limits

Sitecore currently documents these limits for the Profiles UI:

Limit	Value
Visitors listed	500 most recent
Sessions per profile	40, from the previous 90 days
Events per session	100
Client IDs per profile	10

These matter more than they look. On a busy production site, your test visitor from yesterday may already have dropped out of the 500. And a profile showing 40 sessions doesn't mean the visitor only had 40. Treat Profiles as an investigation tool, not a historical data warehouse.

Step 3: Find the profile you need

1. Filter by profile type if you already know whether the visitor should be Visitor or Identified.
2. Search using an identifier supported by your configured identity rules, for example the email used to sign in.
3. Open the matching profile.

Search only works on identifiers your identity rules support. If your rule is email-based and you search by a loyalty number, you'll get nothing, and it's easy to misread that as "the profile doesn't exist."

Step 4: Read the profile Overview

The Overview shows:

• Identity details
• Engagement metrics
• Temporal usage patterns
• Device usage
• Content affinities
• Session locations

If the profile is still a Visitor after a test login, stop. Don't touch personalization yet. The break is somewhere between the login and the identity rule, and that's where you look next.

Step 5: Inspect sessions and events

Sessions are the timeline behind the profile. Open the sessions view and work through these questions:

1. Which pages were viewed?
2. When did each session happen?
3. Which device was used?
4. Was an IDENTITY event captured, and in which session?
5. Did the visitor view pages that carry affinities?

This turns "personalization didn't work" into "the visitor viewed two Personal Loan Article pages, but neither has an affinity configured." That's a five-minute fix.

One thing I check early: whether the IDENTITY event appears in the same session as the login. If it shows up a session later, or not at all, the front end is usually firing it at the wrong point in the page lifecycle.

Step 6: Check affinity scores

If pages have affinities, the profile shows the scores that visitor activity produced. Scores update during a session and are saved to the profile when the session ends.

An illustrative example of what you're looking for:

loan_type 

     Personal                0.72
     home                     0.18

 customer_segment 

     salaried                 0.61 
     business_owner    0.24

Treat these as system-generated signals, not customer attributes someone entered. Don't design audience rules that depend on a specific score value appearing. Affinity-based personalization conditions check which value is highest within an affinity name, so the useful question here is "is homeloan the top value for loan_type?" not "is the score above 0.7?"

Step 7: Troubleshoot with the profile

Two scenarios cover most of the tickets I get.

Scenario: personalization doesn't trigger

Resist editing the rule. Check in this order:

1. Does the visitor's profile exist?
2. Are the expected VIEW events present?
3. Do the viewed pages carry the required affinity?
4. Is an affinity score present for that name?
5. Is the expected value actually the highest within that name?
6. If the variant requires identity, is the profile Identified?
7. Does the condition use the exact affinity name and value, character for character?

Most problems surface by step 3. The last one catches the rest: loan_type in the condition, loantype on the page.

Scenario: two devices appear as separate visitors

This is an identity problem, not a personalization problem. Check:

1. Did the visitor actually sign in on both devices?
2. Was an IDENTITY event captured on each?
3. Does the identifier match what the identity rule expects, including format?
4. Is the identity rule configured in the environment you're testing?

That last one bites more than it should. Rules configured in a dev environment don't follow you to UAT.

Verify the implementation

Add profile validation to your release testing. It takes about fifteen minutes per journey:

1. Browse anonymously in a clean browser and confirm a Visitor profile appears.
2. View pages with affinities and confirm scores appear.
3. Sign in and confirm the profile becomes Identified.
4. Repeat on a second device, sign in with the same identifier, and confirm the sessions sit on one profile.
5. Load a personalized page and confirm the variant matches what the profile shows.

Common mistakes

Expecting data immediately. A sparse profile usually means an event gap, not a Profiles issue.

Using Profiles as the full history. The display limits make it an operational view, not an archive.

Debugging personalization without opening the profile. The profile tells you whether the signal exists before you question the rule.

Ignoring identity resolution. Fragmented profiles make journeys look incomplete, and the affinity picture gets split across them.

Real project tips

The biggest thing to get right is the event model. A weak event implementation gives you thin profiles, weak insights, and poor personalization decisions downstream. You can't fix that in the Profiles UI.

Before handing Profiles to business users as a validation tool, confirm that VIEW events are captured correctly, IDENTITY events fire at the right business moment, identity rules match your approved identity strategy, and affinity names follow a controlled convention. For multi-site solutions, make sure everyone understands that affinities are configured per site.

Plan privacy early too. Sitecore documents profile deletion for a right-to-be-forgotten request as a support-case process for organization admins and owners. Give it a named owner before the first request arrives.

Summary

Work backwards from the profile. When a signal is missing, decide whether the gap is in event capture, identity resolution, affinity configuration, or audience evaluation, then fix it there. Used that way, Profiles stops being a reporting screen and becomes the fastest diagnostic tool you have in SitecoreAI.

References