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

Two decisions happen in this flow. The identity rule decides whether an incoming IDENTITY event matches an existing profile. The affinity calculation decides which interests a page view strengthens.

Failures almost always happen on the left branch: the rule exists, but the IDENTITY event never fires, uses the wrong provider, or fires too early. The UI configuration isn't the hard part. The event pipeline is.

Part 1: Configure identity resolution

Step 1: Choose your identifier

By default, an environment has no identity rules. You can create up to five, but most implementations need one or two. Email is the common choice.

For each candidate, check that it's stable, unique within your customer base, reliably available in the IDENTITY event, and acceptable under your privacy rules. A shared family email will merge people who shouldn't be merged. Pick an identifier because it's trustworthy, not because it's available.

Step 2: Create the identity rule

1. Open Performance - Settings - Identity rules settings for your environment.
2. Create a new rule.
3. Select the identifier (for example, email) that incoming IDENTITY events will use.
4. Save the rule

With an email rule in place, an IDENTITY event using the email provider is compared against existing profiles holding the same email address.

Step 3: Understand the profile states

SitecoreAI tracks three profile states, and you'll see all of them during testing:

• Visitor: created automatically for a new, anonymous visitor.
• Identified: holds identifying information received through an IDENTITY event.
• Retired: a duplicate that has been merged into another profile and is no longer active.

When QA reports "my profile disappeared," it was usually retired and merged. That's the feature working. Brief testers on this up front.

Step 4: Send the IDENTITY event

The rule does nothing on its own. Your application must send the identity information at the right moment, typically right after a successful sign-in or registration.

Two things I check on every project. First, normalize the identifier in your own code before sending it (trim whitespace, consistent casing for email) so you're not relying on assumptions about how matching handles variations. Second, make sure the event fires after the visitor's session exists. Firing it too early in the page lifecycle is a common source of "the rule never matches."

Part 2: Configure affinities

Step 5: Define your affinity taxonomy

An affinity is a name/value pair attached to a page. The name is the attribute you're tracking; the value is the specific interest.

Start from business concepts, not CMS fields. An finance site might use:

• loan_type = home, auto, business, education
• loan_purpose = debt_consolidation, home_purchase, refinance, renovation, vehicle_purchase, wedding, travel
• customer_segment = salaried, self_employed, business_owner, student, retiree
• rate_preference  = fixed, variable
• Sitecore recommends only a-z, 0-9, and underscores. 

Step 6: Assign affinities to pages

1. Open Performance.
2. Select Settings > Affinities.
3. Select the site.
4. Select the page you want to tag.
5. Click Add affinity.
6. Enter the affinity name and value.
7. Save.

A page can carry up to 10 affinities. Affinities are set per page and don't carry across to other sites, so a multi-site solution needs the taxonomy applied site by site.

I tag detail pages first. A model page says far more about intent than a landing page everyone passes through, and tagging navigation pages inflates scores for whatever they carry.

Step 7: Let behavior build the scores

Once pages are tagged, SitecoreAI calculates affinity scores from VIEW events as visitors browse. Scores update in near real time during a session. When the session ends, they're saved to the profile and kept for up to 30 days.

So affinity is a moving signal. A visitor who starts on home and then reads home loan article pages shifts toward rate_preference = fixed.

Part 3: Use affinities in personalization

Step 8: Build an affinity-based condition

1. Create or open a personalization variant.
2. Add an affinity condition.
3. Enter the affinity name, for example loan_type.
4. Enter the affinity value, for example personal.
5. Save and publish the variant.

The condition is satisfied when suv is the visitor's highest-scoring value within loan_type. It's a "top value" check, not a threshold. A visitor with a small interest in personal loan but a bigger interest in home loan won't match.

Type the values exactly as they appear in your taxonomy. A mismatched value doesn't throw an error. It just never matches.

Verify the configuration

Run this end to end, ideally in a clean browser profile:

1. Visit the site anonymously and confirm a Visitor profile is created.
2. Browse several tagged pages and confirm affinity scores appear and change.
3. Sign in and confirm an IDENTITY event is sent with the expected provider and identifier.
4. Confirm the profile becomes Identified.
5. Repeat on a second device or browser, sign in with the same identifier, and confirm the duplicate is Retired and the activity sits on one profile.
6. Load a page with your affinity-based variant and confirm the right content shows.

Checking only the SitecoreAI UI confirms the configuration exists. It doesn't confirm the data path works. Watch the network requests in dev tools while you test.

Common mistakes

Identity rule configured, no IDENTITY events sent. The most frequent issue by a wide margin. The rule can't match what never arrives.

Treating email as a behavioral signal. Identity tells you who. It tells you nothing about intent.

Inconsistent affinity names. Variations of the same concept split scores and break conditions.

Expecting untagged or other-site pages to contribute. Only tagged pages on that site feed the score.

Troubleshooting

If profiles aren't merging, start at the browser, not the UI. Is the IDENTITY event present in the network traffic? Does it carry the provider your rule expects? Is the identifier formatted the same way across devices?

If affinity scores stay empty, check that VIEW events are firing on the tagged pages and that you tagged the right site. I've seen teams tag pages on a staging site and then test against production.

If a personalization variant never shows, compare the name and value in the condition character by character with the page configuration, then check whether another value in the same affinity name is actually the visitor's top score.

Best practices and real project tips

Assign three owners before launch: someone for identity governance (identifiers, privacy, matching strategy), someone for event quality (reliable VIEW and IDENTITY events), and someone for the affinity taxonomy. When these belong to nobody, they degrade within a few months.

Test across anonymous sessions, identified sessions, multiple devices, and repeat visits. Most identity problems only appear in the second-device test, and it's the one QA skips most often.

Keep the initial taxonomy small. A few affinity names with a handful of values each is enough to prove value.

Summary

Identity resolution and affinities solve different problems, and each is weaker without the other. My order on any SitecoreAI implementation is fixed: settle the identity strategy, prove the event pipeline, then introduce a controlled affinity taxonomy. Personalization built on that foundation holds up. Personalization built before it tends to look fine in a demo and fall apart on real traffic.

References

Decoupling is the right call — Identity Server has its own patch cadence and pinning it to the platform release train was always awkward. The practical cost is that your Azure PaaS architecture and IaC change, and there is a data migration rather than a fresh install.

That migration is the step people skip. A clean Identity Server starts up happily, then fails to authenticate existing users — and because it presents as a login problem rather than a deployment problem, it gets found by whoever logs in on a Friday afternoon.

Pin down early	Why
IdS data migration	Fresh install ≠ working auth for existing users
Client IDs / secrets for CM and custom clients	Secrets now cross an extra deployment boundary
Redirect URIs	Must match the new topology
Custom IdS plugins (ADFS, Entra ID, custom login)	Move with the module — need their own build/deploy path
Application Insights config	Connection strings only; instrumentation keys are gone

App Insights deserves its own flag: a one-line fix per environment that, missed, makes a deployment look successful while telemetry quietly goes nowhere.

Security by default, and what it costs you

The security work is the part I'm most positive about and the part most likely to break a build.

Change	What breaks	What you do
BinaryFormatter removed	Custom caching, session state, object serialization — yours or a third party's	Real serialization change (System.Text.Json, protobuf). Grep for it before planning anything
Package Installer / Designer disabled by default	Any deployment pushing .update or .zip through the installer	Move to serialization-based deployment; if you must, enable explicitly in non-prod only
Deprecated JS libraries removed	Shell extensions and custom Content Editor UI leaning on whatever jQuery sat in /sitecore/shell	Audit custom shell UI dependencies
GraphQL Playground removed	Developer workflow	Postman, Insomnia, or Altair against the endpoint
Microsoft.Azure.ServiceBus → Azure.Messaging.ServiceBus	Compile break on any messaging code	Update references and API calls
Vulnerability chains fixed, dependencies tightened	Nothing	This is the argument for the whole project

The first two are unambiguously correct decisions. The installer is a remote code execution primitive by design; leaving it enabled on a production CM has caused real incidents.

The quiet operational wins

None of these need action. They're why a 10.5 environment feels better under load, and useful ammunition when someone asks what the business gets from an upgrade with no visible features.

Pre-flight before you touch a package

Get that last row done in week one. Finding it in week six is the classic way these projects slip.

Then upgrade in a throwaway environment first, on the new infrastructure, with migrated Identity Server data in place. Regression-test search hardest — that's where the bodies are.

What I'd tell a teammate

Don't let this be estimated as a Sitecore upgrade, because the Sitecore part isn't the hard part. Solr 10 and Identity Server 8 reshape your architecture, and both touch teams outside the Sitecore team — infrastructure, networking, whoever owns the WAF rules. Get those people into planning rather than into the incident call.

The security posture is the strongest argument for doing it. Removing BinaryFormatter, disabling the Package Installer, closing the vulnerability chains — that's the platform taking responsibility for defaults that used to be yours to remember. If you're running classic XP and expect to keep running it for a few more years, this release is what makes that a defensible plan rather than accumulating risk.

It just costs more than the release notes make it look.

References

• Sitecore Experience Platform 10.5 — downloads
• Sitecore XP 10.5 release notes
• Sitecore XP 10.5 breaking changes
• Sitecore XP 10.5 developer documentation
• Upgrade guide for Sitecore XP 10.5
• Sitecore compatibility table (KB0087164)