In my previous blog https://blogs.perficient.com/2024/07/01/sitecore-personalize-close-event-logic/, I shared a method for using cookies to enable the user to dismiss an alert banner.  This process involved writing the cookie when the user clicks the close icon and checking for the cookie when the experience is displayed.  This approach worked well because the entirety of the javascript code could be stored in the web template.  This ensures the code to check for the cookie can’t be missed or forgotten when the template was used.  Unfortunately, this had an unintended side effect.  Personalize still executed the experience and counted it in the analytics and performance metrics even though the javascript never added the elements to the screen.  This lead to overinflated metrics and the inability to use the data for accurate forecasting.  This problem can be overcome with advanced page targeting.

Advanced Page Targeting

Advanced page targeting allows you to run client side javascript to decide if an experience should execute.  Since the javascript runs client side, you can read the url and query string parameters, you can access the console to log messages, you can access the document object to query selectors on the page, and of course read cookies.  Advanced page targeting javascript runs after the page loads, but before the experience loads which allows us to prevent the experience from executing and overinflating analytics.  Be sure to keep your script as lean and performant as possible to reduce the possible screen flicker of loading the experience after the page has loaded.

Checking Cookies with Advanced Page Targeting

In order to use advanced page targeting, you must select the “specific pages” setting under “Page Targeting”.

Enable page targeting on specific pages to enable advanced page targeting

In the flyout window for page targeting, add any filters for pages where you want the experience to display.  If you want the experience to display on all pages, simply use the contains “/” rule.  In the advanced targeting section, click the “add script” button.

Configure advanced page targeting

In the advanced targeting code editor, enter the following code.

(function() {
   // console.log(new Error().stack);

    var cookies = document.cookie.split(';');
    for (var i = 0; i < cookies.length; i++) {
        var cookie = cookies[i].trim();
        if (cookie.indexOf('pers-' + selectedVariant.ref + '=clicked') === 0) {
            return false;
        }
    }

    targetingPassed();
})();

In my previous blog, I created the cookie using the variant.ref as part of the cookie name.  This adds the guid of the current experience id to the name of the cookie making it unique even when the web template was reused.  Advanced targeting does not have access to the variant.ref property.  So it doesn’t work with the close event logic idea I came up with before.  However, there is a selectedVariant.ref property that you can use.  Using selectedVariant.ref works for both experiences and experiments as it can dynamically get the correct guid of the current variant at run time.

When personalize evaluates this block of javascript code, it only continues processing the flow of execution for the experience if the “targetingPassed()” function is called.  If you want to stop the flow of execution, return false.  In our case, we want to stop the flow of execution if the cookie is found.  Otherwise we can call the targetingPassed() function and allow the experience to display to the user.

Once you have added advanced targeting javascript, you can edit the script by clicking the pencil icon.

Edit advanced page targeting settings

Edit advanced page targeting script

Things to Know About Advanced Page Targeting

As mentioned, this solution solves the problem of overinflating analytics.  The downside is the advanced page targeting settings and code cannot be saved with the web template.  So the marketer or content author must remember to enable this setting and add the javascript code to the experience.  If the code is not added, the user will be able to close the experience, but it will display on the next page load since the code to check for the cookie is missing.  One other thing to note, if you change your page targeting settings back to “all pages”, the advanced targeting script is deleted from the experience.  In both cases, ensure that it is easy for content authors to find and reuse.

Searching for content on the web has evolved from basic string based matches to a sophisticated array of approaches including keywords, stemming, synonyms, word order, regular expressions, weights and relevance.  Users expect the highest ranking results to be the most relevant and 75% of users don’t go past the first page of results.  All of these advanced techniques are great to find relevant content.  But sometimes you need to find an exact phrase with the specific words in a specific order.  Many search engines do this by wrapping quote marks around the “search term” to indicate an exact match search. Sitecore Search defaults to relevance based searches, but you can achieve exact match search with some configuration.

Understanding Sitecore Search

Let’s take a moment to remember a few concepts in Sitecore Search to understand the configuration better.

• Index Document – A single piece of indexed content such as a webpage, a word document, a pdf, etc.
• Attributes – The fields of an indexed document such as title, subtitle, url, content type, etc.
• Textual Relevance – Defines the attributes used to locate potential results.
• Weight – Defines a relative value for how important an attribute is within the textual relevance.
• Analyzers – Convert the original search query into a format that is optimized for search.
• Token – A chunk of the original search query, usually a single word or phrase that is often modified by the analyzer to include synonyms, remove stop words and reformat to the root word.

Sitecore Search has a number of predefined analyzers built in.  Each analyzer processes the search query in different ways.

The default analyzer is the multi local standard analyzer.  This analyzer modifies the search query by making it lower case, splitting the search query into single word tokens, finding the root of each word, applying synonyms, and removing punctuation.  For this reason, it will not find an exact match.  For that we need the keyword analyzer which leaves the search query in a single token without applying any modifications.

Configure Exact Match Search – Textual Relevance

In order to configure exact match search, we need to add the keyword analyzer to the textual relevance settings for the desired attribute, in this case the description.

Navigate to Admin/Domain Settings then click the feature configuration tab.

Domain Settings

Edit the Textual Relevance section.

Textual Relevance Settings

Add the keyword analyzer to the description attribute.

Add Analyzer

Select the keyword analyzer

Make sure to save your changes then publish your domain settings for your changes to take effect.

Configure Exact Match Search – Widget Settings

Next we need to configure our search widget to use our textual relevance settings.

Navigate to a widget variation and click add rule.

Add rule to a widget Variation

Click the top icon on the left to set the site context.  Add a context rule for Keyword and select the contains option.  In the input box, type a single quote mark.

Add keyword rule to the site context

Click the bottom icon on the left to configure the settings.  Click the tab for Textual Relevance and click the toggle to enable the configuration.  Notice that the description field is listed twice, once for each analyzer. From here you can enable/disable each attribute/analyzer and set its relative weight.  In this example, I’ve set the description-keyword to 3 and the name-multilocal to 1.  This will do the exact match search only on the description attribute.  You could include name-keyword analyzer to do an exact match on the name as well if that is desired.

Description keyword rule

Repeat the process to add or modify a second rule that uses the description-multilocal analyzer.

Description multilocale rule

This rule will be the fallback if the search term does not include a quote.

Rule order and fallback

Exact Match Search in Action

With this configuration in place, you can see the difference in the search results.  In this example, I’ve searched for “proxy statements”.

When you include a quote mark in the search term, you only get results that have the exact phrase “proxy statements”.  This search returns 12 results.

Exact match search with 12 results

When you do not include the quote mark in the search term, you get results that include proxy, statements and statement.  This search returns 68 results.

Relevance search with 68 results

Sitecore Personalize uses goals to track the performance of experiences and experiments.  But what happens if your experience is live and you don’t see any executions or goals tracked in the performance tab for the experience?  It can be hard to debug, test and troubleshoot goal tracking especially if the experience is hidden behind a login for example.  But you can trigger the goal programmatically by making a series of api calls.  I’ve created a Postman collection that you can download to make the process easy!  Just update the environment with the appropriate values and you’ll be able to trigger your goals in no time!

Postman collection details

Setup the experience

Image showing the custom goal details

Create your experience using any variant, page targeting and filtering settings.  Expand the goals section and ensure “track performance” is selected, then click Add goals. In this example, I’m using a custom goal. Give your goal a name and set your performance targets. Add the name of your custom event under “track event” and click the save button.

Make sure to preview your experience to ensure it displays properly.  But keep in mind that an experience must be live in order for the system to track goals.

Trigger the goal

In order to trigger a goal in Sitecore Personalize the experience must be viewed in the same session as the goal event.  I’ve setup a postman collection that simulates a user navigating the site, triggering the experience and executing the custom event.

Session details that match the api calls

In order to track your guest, you need a browser id (even for api calls).  You can obtain a new browser id by using the “Get Browser Id” call in the postman collection or by using your existing browser id from your browser.  To get your existing browser id, open your browsers dev tools and enter the following command in the console.

engage.getBrowserId()

You can update the environment vars in the postman collection to use your existing browser id.

Once you have your browser id, we will simulate the user journey through the site.  I have included 5 page view calls in the postman collection along with 5 page variables.  Set the urls of the pages you want to call, then execute the VIEW requests.

After you have made a few view requests, you’ll want to trigger the experience.  You’ll need the friendly id of the experience which can be found on the experience page in the grey details box.  Add this name in the environment variables for the postman collection the run the “Trigger Experience” request.

Image showing location of friendly id

Once the experience is triggered, you can trigger your custom event.  Add the custom event name and page url to the environment variables, then execute the “Custom Event” request.

In this example, we have triggered a goal for an experience using a custom event.  You can just as easily trigger a page view goal by executing a VIEW request to the proper page after triggering your experience.  Similarly, you may want to trigger the identity event if your experience requires the user to log into your site.

It is important to note that the goal will not appear on the report until the browsing session is closed!  Your point of sale has a timeout period that will close a browsing session after X minutes of inactivity.  When you are testing, you can execute the FORCE CLOSE request to end the session manually.

Check the data

Once you have triggered the goal and the session has ended, check the performance and operational data of the experience to validate the goal was triggered properly.  You will see the successful execution of the experience in one graph

Graph showing successful execution of experience

and the primary goal in a separate graph.

Graph showing triggered goal

You can now be confident that your goal is configured correctly and Sitecore Personalize is tracking your goal correctly.

Welcome to my recap of Sitecore Symposium 2024! The week continued with numerous insightful sessions, informative workshops, and exciting new announcements. Here are my session notes and takeaways from the final day at Symposium, day three.

Opening Keynote

Opening keynote with Brendan Hunt

The morning kicked off on a high note with a special guest appearance by Brendan Hunt, who plays Coach Beard on Ted Lasso. Though I haven’t watched the show myself—there are simply too many good ones to keep up with —I still found his insights engaging and relevant. He shared valuable lessons that resonate in both work and life, without needing to be star-struck to appreciate them.

• How to make work not suck
  • Connect with co-workers.
  • Surprise your co-workers.
  • Make today different than yesterday.
    • Don’t fall into the trap of the mundane.
  • Be curious, not judgmental.
    • People have lots of things going on that might not be apparent or shared with you.
  • Don’t let the wisdom of age be wasted on you.
    • Use the knowledge that you have gained.
    • This is the opposite of youth is wasted on the young.

CDP and Personalize at Scale

CDP and Personalize at Scale session

Personalization at scale holds immense potential for boosting revenue, and companies that successfully tackle the challenges of scaling personalization will gain a competitive edge. In today’s market, can your business afford not to invest in personalization? While personalization can drive growth, it comes with its own set of challenges—overcoming these will set industry leaders apart from the rest.

• Challenges faced by marketers
  • Creating the right content.
  • Creating enough content.
  • Creating quality content.
  • Technical skills to create content.
  • Understanding what the customer wants/needs.
• Data
  • Ensuring you have the data you need to personalize.
    • Data is often trapped in multiple disconnected systems.
  • Distribution
    • Coordination between channels to ensure a consistent customer experience and messaging.
  • Scaling
    • Content reuse
      • Integrate Sitecore Search to surface existing content.
    • Generative AI
      • Content creation and revision.

XM Cloud Roadmap

The benefit of a SaaS-based product like XM Cloud is that it is being continuously updated. Best of all you get the updates without having to upgrade. XM Cloud has numerous new features coming to the platform.

• Present
  • A/B Testing
  • Marketer’s Dashboard
  • Sitecore Stream content optimization
• Next
  • Updates to Pages
  • Component level personalization
  • Component Library
  • Sitecore Stream brand assistant
• Future
  • Generative AI component builder
  • Embedded Search

Sitecore Lunch

Lunch with friends in the Sitecore community

What a great way to end a great week! An in-person Sitecore lunch started as two tables and then grew to four, six, and eight tables with almost 40 people. This shows the real power of the Sitecore community because although we might work for different companies and be considered “competition”, we can still be friends and discuss Sitecore without boundaries. With my Perficient colleagues, it’s so nice to sit around a physical table with everyone that I normally see every week in little boxes on a Zoom call.

That’s a wrap!

Sitecore Symposium 2024 is over, but there is so much to look forward to in the world of Sitecore over the next year. I’m thrilled about the upcoming changes in CDP, Personalize, and Search with unified tracking, as well as the potential of Sitecore Stream for AI-driven insights, content creation, and brand-aware marketing support. I’m also looking forward to the Sitecore Marketplace, where we can build apps and expand the capabilities of XM Cloud. Feel free to connect with me on LinkedIn. I’d love to chat and hear more about what Sitecore news you are most excited about.

Welcome to my recap of Sitecore Symposium 2024!  Day 2 at Symposium offered incredible insights and valuable information. There was no shortage of engaging sessions and thought-provoking discussions and we are so excited to bring these fresh perspectives back. Here are my session notes and takeaways from day two.

Women in Digital Breakfast

What an inspiring way to start the day! Sitecore and Perficient joined to bring the inaugural Women in Digital Breakfast to life. The morning started with a nice breakfast buffet and there was time to hang out and connect with other attendees. Perficient continued our “Skip the Swag” initiative and left notecards on the tables where each attendee could write and share how cancer has impacted their life. For each attendee, Perficient will make a donation on their behalf to the American Cancer Society. The panel discussion was very well done and the speakers had great insight and takeaways.

• How can men help support women in the workplace?
  • Create space for women.
  • Bring women along on your journey.
  • Stand up for your women colleagues.
  • Be an ally.
• How can we help to eliminate gender roles in future generations?
  • Raise boys and girls with the same standards.
  • Do not force kids into certain roles, hobbies, or toys that play to gender stereotypes.
• Many women left the workforce during the pandemic to support kids and families but now…
  • They are coming back.
  • They are changing careers.
  • They need support.
• How can we support women with families (or anyone with a family really)?
  • Be understanding.
  • Family comes first.
  • Work is a part of life, not your whole life.

Opening Keynote

Eric Stine opened the day with the announcement that Content Hub, XM Cloud, and CDP are all HIPPA compliant! This is a big deal since it allows Sitecore to be able to sign BA agreements with healthcare organizations. In today’s modern world, users expect personalized experiences but this is difficult when it comes to PHI. You cannot change your personal information like you can your credit card if you get hacked. Protecting personal information is important to a brand’s trust.

Experience Awards

The morning continued with the announcement of the Experience Award winners for 2024.  Perficient was pleased to win the Global Sitecore Practice Excellence Award. You can see a full list of all the winners in Sitecore’s official press release. Congratulations to all the winners!

Sitecore Search at Scale

This project included 6 sources, 7000 PDFs, and 44 languages! How do you scale Sitecore Search to a project that large?

• Identify your data
  • What you want to index.
• Analyze the data
  • How can you standardize your data?
• Expose your data
  • Sitecore Search uses a crawler, so it must be able to access your data in order to index it.
• How will Search help your clients?
  • What problem are they trying to solve?
  • What are they looking for?
  • Is the data useful to your clients?
• “Make it like Google”
  • Google has hundreds of developers solely focused on search.
  • Your development team is likely much smaller and has many other tasks to accomplish to launch a site.
  • Your search experience is only as good as the time and money you can devote to it.

Introducing Sitecore Marketplace

More people are moving to XM Cloud and other SaaS products. 82% of users say that an app marketplace is an important factor in choosing a DXP platform. Sitecore is taking that information to heart and creating a new Sitecore Marketplace. This will be a fully supported solution for discovering, enabling, and managing apps, plugins, and extensions.

• This gives developers
  • The tools and technologies to create add-ons for Sitecore products
    • SDKs
    • UI libraries
    • Support and documentation
    • Starter library
  • Support for app versions
  • App visibility
    • Public
    • Private (invite only access)
  • This gives customers
    • The ability to add new features and capabilities to their instance

Sitecore CDP – Unified Tracking

Sitecore’s composable suite of products are becoming easier to connect together. Unified tracking means that you only must integrate one SDK. It also means that each event triggered will persist across all Sitecore products. The first products to use unified tracking will be XM Cloud, CDP, Personalize, and Search.

• Session Tracking
  • A new session end event in CDP that allows you to update the guest profile.
• Profile Sharing
  • The guest profile can be shared across products.
    • Use the guest ID in CDP to find the same user in Search.
  • Audience segments can be shared across products.
    • Search results can be tailored to the audience segment.
  • Cloud SDK
    • One SDK to rule them all.
      • The Cloud SDK will reach feature parity with the Engage SDK.
      • The Cloud SDK will be the primary and best way to integrate

Symposium Party

Sitecore sure knows how to throw a party! We had bus service to downtown Nashville where we had space at four bars on Broadway just for attendees! There was a buffet with all the southern comforts including my favorites: chicken and waffles and shrimp and grits!  To top it off, there were three floors of entertainment and a rooftop with a view of downtown. There was live music, line dancing, drinks, and good times with good friends!  What a great night and great experience at Sitecore Symposium!

Welcome to my recap of day one at Sitecore Symposium 2024! There was no shortage of inspiring sessions, key takeaways, and exciting announcements from day one.

Opening Keynote

The opening keynote by Sitecore executives was an excellent kickoff to Symposium, reinforcing their commitment to being a trusted partner. They emphasized their focus on core strengths and want people to have a choice, whether it be XM Cloud, XM, or XP. Sitecore is determined to stay ahead of the market through innovation and they made several exciting announcements about the direction they’ll take in the coming year. It’s an exciting time to be working with Sitecore!

Introducing Sitecore Stream! Sitecore Stream is the new brand-aware AI generative copilot that will work with marketers as they try to do more with less.

• Will be integrated across all DXP products
• Shortened time to value.
• Keep marketing materials consistent.
• Help create new campaigns.
• Balance strategy with technology.

It really is an impressive tool and I, along with many others in the Sitecore community, can’t wait to see it in action. You really do have to see it to believe it.

Accessibility and the Impact on your Business

Accessibility is more important than ever, yet it’s often treated as an afterthought, typically addressed at the end of projects when it should be prioritized from the start. It’s not just about checking a box or a one-and-done effort—accessibility affects everyone and can benefit anyone. Good website design enhances the user experience for all, not just those with disabilities.

• Why is accessibility important?
  • Regulatory
  • Legal
  • Financial
  • Equality
  • Doing the right thing
• ADA lawsuits:
  • The number of lawsuits is rising over time.
    • In 2018 there were 2,000+ Lawsuits.
    • In 2023 there were 4,000+ lawsuits.
  • According to the ADA, 72% of lawsuits were against companies with less than 50 million in revenue.
    • Small companies are at just as high of risk as large companies.
  • Statistics:
    • According to the CDC, 28.7% of people have a disability.
    • UNC School of Medicine found that 71% of web users with a disability will leave a site if it is not accessible.
    • This equates to a potential 20% loss of revenue.
      • Can you afford to not be accessible and lose this amount of business?
    • Doing the right thing:
      • It can increase your reputation.
      • It can generate loyalty.
      • It’s a key differentiator.
      • It’s a marketing opportunity.
      • It makes the world better for everyone.

Is AI Bias the New Elephant in the Room?

Bias is an unfavored weight towards one group of people. How does this affect generative AI? Test it yourself: create an image without specifying details like age, gender, or race. What results do you see? Chances are, the image lacks cultural diversity, and representation of people with disabilities, or older individuals. It may also reflect assumptions about gender roles based on job titles.

• How AI bias happens:
  • Algorithmic bias during the development of the model
  • Data bias in the model training phase
  • Interaction bias when the AI learns from biased human interactions
• What is the impact of bias?
  • Legal and ethical consequences
  • Lost revenue
  • Erases diversity
• How can we reduce this bias?
  • Add diverse perspectives when building the algorithms
  • Train people to identify bias in generative AI results
  • Reward people doing good work

Sitecore Search Product Roadmap

Sitecore Search is continuously evolving like many other SaaS products. Take a look at the future of Sitecore Search.

• Current
  • Commerce product grouping
    • Group similar products on product or size variations
  • Commerce rules
    • Bury low or out-of-stock items
  • CDP
    • Audience segment support
  • Next
    • Unified tracking.
      • Tracking IDs will work across many of Sitecore’s composable products
    • XM cloud content indexing
      • Push changes directly into Search
    • Order cloud integration
    • Generative AI Q&A for search prompt
    • More accurate recommendations
  • Future
    • Refined UX
    • Simplified indexing connectors
    • Copy rules between instances
    • Exposed search analytics
    • Conversational search
    • Generative AI metadata

Sitecore Symposium 2024 is Underway!

A conference like Sitecore Symposium is a great way to make a mini vacation out of your work travels. I arrived on Sunday and explored the city of Nashville. Did you know that Nashville is home to a full-scale replica of the Parthenon? It was built in 1897 as part of the Tennessee Centennial Exposition. Today, it’s the only remaining building from the exposition and has since been turned into a museum. The museum contains the largest indoor statue in the Western Hemisphere, the goddess Athena in full gold leaf standing at 41ft tall.

Symposium is being hosted at the Gaylord Opryland Resort. This is my first time here and the hotel is beautiful. The atrium is covered in glass and has lush green gardens and walking paths with waterfalls. You can even take a boat ride through the interior.

For me, the best part about these conferences is seeing people face-to-face! Most of us work remotely and are only able to see these people on phone calls and little boxes on our screen in a grid on a zoom call. It’s great to see people in person, face-to-face because technology can’t replicate that experience.

Exploring Nashville

The conference schedule fills up quickly, so having time beforehand to hang out with friends is great. Chet Potvin  organized a walking food tour of Nashville on Sunday night. We started out at a rooftop bar with a great view of downtown Nashville. The guide shared some great stories about Nashville history, culture, music, and food. We had four stops, which included Nashville barbecue and the famous Nashville hot chicken.

MVP Summit

Monday was the MVP Summit. This was my first time attending. While I can’t share any of the information from the sessions, I can say it was a great experience. We got a sneak peek of inside information and got to interact with the Sitecore product teams and executives. We had interactive conversations and it’s great knowing that the team at Sitecore really listens to our feedback. As MVPs, we are really able to impact the products.

MVP Party

After a full day of sessions, we were treated to an MVP party at Dave and Buster’s. Sitecore booked the entire venue just for us. We had great food and drink, unlimited gaming, and karaoke. It was a great time to hang out with old friends and make new friends.

Tiffany, Josh, and I challenged Dave O’flanagan to a race of Mario Kart! MJ is quite the instigator and isn’t afraid to let loose and encourage others to do the same. We did a great version of Ice Ice Baby. And in case you’re curious, yes, we know all the words. The night ended with 15 people singing Closing Time. But we weren’t done yet. On the walk back to the hotel, we gave our best acapella version of Sweet Caroline. It was so good so good so good! What a fun night! It’s the reward for a full year’s worth of hard work to achieve MVP status.

Looking Ahead to Symposium

I’m looking forward to seeing what more Sitecore Symposium has to offer. It promises to be full of innovation, collaboration, fresh insights, and informative sessions. If you’re attending Sitecore Symposium, stop by our Perficient booth!

Sitecore CDP tracks user behavior by linking browsing session, events, and orders to a guest profile.  By default, guests are marked as “visitors” meaning we do not know who they are.  A guest can become a “customer” meaning we know who they are. In order to identify a guest, we must send an “IDENTITY” event.  An identity event is a specific type of event that tells Sitecore CDP to begin the identity resolution process.  This process is well documented.  I read through this documentation multiple times and did not really understand the process until I needed to implement it for myself.  If you have been confused by identity in CDP, read on!

Background

A guest profile is created when you browse a site.  Your guest profile is linked to your browser through a browser id.  By default your guest profile is has the status of visitor.  In order to identify as a customer, you must send an IDENTITY event.  Any time you collect a piece of information that identifies the person, you can send the IDENTITY event.  This event can be the result of logging in, filling out a contact form, or registering for a newsletter.  When you send an identity event, you send an identifiers attribute in the event object.  This identifiers attribute has properties for provider and id.

var event = {
    "channel": "WEB",    
    "language": "en",
    "currency": "USD",
    "page": window.location.pathname + window.location.search,    
    "email": "clint.barton@shield.gov",
    "firstname": "Clint",
    "lastname": "Barton",
    "identifiers": [
        {
            "id": "clint.barton@shield.gov",
            "provider": "email"
        }
    ]
}

engage.event("IDENTITY", event);

Identity Resolution

When you send an IDENTITY event, CDP will store the identity values in the identifiers array of the guest linked to your browser id.  CDP will use the string value in the provider property and search all guests for a matching id within the same provider. If none are found, it changes the status of the guest profile to “customer” since it now knows who you are.  If it does find another customer with the same provider/id, it merges the current guest visitor profile with the existing guest customer profile.  This process is called identity resolution.

The identity resolution process makes more sense if you enable debug mode for CDP and look at the properties of a guest.  CDP has an internal property called “identifiers” for each guest.  Notice how the properties you sent in the IDENTITY event are stored with the guest.

CDP debug information showing the empty identifiers property

CDP debug information showing the identifiers property with one provider

Multiple Identifiers

In the real world, we have multiple ways we can be identified: date of birth, social security number, drivers license id, passport id, email, username, account id, etc.  CDP allows the same behavior digitally.  Each guest profile can store multiple identifiers.

CDP debug information showing the identifiers property with two providers

You can send multiple provider/ids in the identifiers attribute of the IDENTITY event.

var event = {
    "channel": "WEB",    
    "language": "en",
    "currency": "USD",
    "page": window.location.pathname + window.location.search,    
    "email": "clint.barton@shield.gov",
    "firstname": "Clint",
    "lastname": "Barton",
    "identifiers": [
        {
            "id": "clint.barton@shield.gov",
            "provider": "email"
        },
        {
            "id": "c_barton",
            "provider": "username"
        }
    ]
}

engage.event("IDENTITY", event);

Identity Rules

CDP uses email by default, but allows you to create up to 5 identity rules.

Identity rules in Sitecore CDP

Imagine that you have an identity rule for username.  In CDP you would define a new rule called “username”.  When you send an identity event, you can pass {provider: username, id: c_barton}.  CDP will store this value in the identifiers property of the guest just like it did with the email.  So now guests have two ways they can be identified.  CDP does not allow you to set the order of the rules.  But you can send the identity providers in the IDENTITY event in the order you want to process them.  If CDP does not find a match with the first listed provider, it evaluates all remaining providers in the order listed.

Conclusion

The most important to know that the identity rules and the identity resolution process is that the provider is just a string label.  You could call it “abracadabra”, “alohomora”, or “Supercalifragilisticexpialidocious”.  Just be sure to send the same string label in the IDENTITY event so the identity resolution process can match guests correctly.

Sitecore Personalize has several out of the box components that notify the user such as popup takeover, corner popup, sidebar, and alert bar.  These components all feature a close icon that will hide the component from the screen.  But there is no logic out of the box to prevent them from being displayed again.

Imagine we have an alert banner that appears at the top of the page.  You use page targeting to run the experience on all pages.  This will ensure the user sees the information when they come to the site no matter what page they land on first.  The user lands on the contact us page and sees the alert banner.  They click the X icon to dismiss the banner and navigate to another page.  The banner appears again.  They click the X icon to dismiss the banner and navigate to another page.  The banner appears again!  What a frustrating experience!  The user thinks, I don’t want to see this banner again!

Here are two ways that you can track the dismiss event and prevent the banner from appearing after it is dismissed.

Using Events and Conditions

Conditions allow you to control when an experience is displayed much like page targeting.  A condition is simply a block of javascript code that can access guest data and events.  A condition returns true if the experience should display and false if it should not display.  This javascript runs server-side.  You have access to the full guest context, but not the client’s browser window.  You can use the same [[parameter | type | default value ]] syntax as in the experience variant or web template to create a user editable form allowing the condition to be customized.

Imagine our alert banner example.  We want to create a condition that searches the guest’s events to see if the alert banner had been dismissed previously.  CDP retains all event data from the last 1000 sessions (https://doc.sitecore.com/cdp/en/users/sitecore-cdp/data-availability-in-sitecore-cdp.html).  Note that if you have a long running experience on a site where users have a high number of sessions, it could be possible that the alert banner could appear again after the session containing the dismiss event has rotated out of storage.  In general, this solution will work across devices once the user has logged in and can tie their session to their guest profile.

(function () {
  var session = guest.sessions[0];
  if (!session) {
    return true;
  }
  for (var j = 0; j < session.events.length; j++) {
    var data = session.events[j];
    if (data.type === "[[Event Name | string | ALERT_BAR_DISMISSED]]") {
      return false;
    }
  }
  return true;
})();

In the output section of the configuration tab, we want to edit the description. Include the parameters in the description so the user can customize the condition for this experience. The description is displayed when the user selects the condition from the experience screen.  The parameterized fields will show in bold.

The configuration tab of a condition

In the preview section at the bottom of the screen, you can see how the text description will be displayed with the bold fields along with a preview of the input mode.

The text preview section of the condition configuration tab

The input preview section of the condition configuration tab

In the web template we will create a parameter that allows the user to give this experience a unique id.  This is important so dismissing BannerA does not prevent all future banners from being displayed.  Notice in this code that we are adding an event listener on the close button.  When the close button is clicked, we are sending an event back into Personalize so the condition can find it the next time the page is loaded.  Notice that we can use Engage.settings.pointOfSale so we do not have to hard code that value.  This value is read from the Engage SDK in the client’s browser.

document.body.classList.add("show-TopBanner");
insertHTMLBefore('body', 'pers-');
// Declarations
const persExperience = document.querySelector("#pers-"+variant.ref+ ' #pers_TopBanner');
const persCloseButton = document.querySelector("#pers-"+variant.ref+ ' .pers__btn-close');

// Declare Pers function event
const sendInteractionToPersonalize = function(interactionType){
    const type = "[[ Experience ID | String | ALERT_BAR | {required: true}]]_" + interactionType;
    const eventData = {
        "channel": "WEB",
        "pointOfSale": Engage.settings.pointOfSale,
    };
    window.engage.event(type, eventData);
}

//Listen on X button
persCloseButton.addEventListener("click", function(){
    persExperience.style.display = "none";
    document.body.classList.remove("show-TopBanner");
    sendInteractionToPersonalize("DISMISSED")
});

When you preview the experience with the condition, the qa tool will show a yellow people mark indicating that it stopped processing at the filter step.

The QA tool showing the yellow people icon

The QA tool stopping at the filter step

This helps with performance because the decision model is not executed and the html/css step is not rendered.

Using Cookies

Let’s imagine our same alert banner but this time using cookies to track if the banner has been dismissed.  When we create our experience, we won’t need to set a condition this time.  Instead we’ll modify the web template to include a check to see if the cookie exists.  We’ll also write a cookie when the alert banner is dismissed.  Notice here I’m wrapping the entire javascript block from before inside an if statement that checks for the cookie.  You can use the variant.ref variable to dynamically get the GUID of the current variant.  We’ll use the variant.ref as the name of our cookie so dismissing BannerA does not prevent all future banners from being displayed.

if (!document.cookie.split(";").some((item) => item.trim().startsWith('pers-' + variant.ref + '='))) {
    document.body.classList.add("show-TopBanner");
    insertHTMLBefore('body', 'pers-');
    // Declarations
    const persExperience = document.querySelector("#pers-" + variant.ref + ' #pers_TopBanner');
    const persCloseButton = document.querySelector("#pers-" + variant.ref + ' .pers__btn-close');
    // Declare Pers function event
    const sendInteractionToPersonalize = function (interactionType) {
        const type = "[[ Experience ID | String | ALERT_BAR | {required: true}]]_" + interactionType;
        const eventData = {
            "channel": "WEB",
            "pointOfSale": Engage.settings.pointOfSale,
        };
        window.engage.event(type, eventData);
    }
    //Listen on X button
    persCloseButton.addEventListener("click", function () {
        persExperience.style.display = "none";
        document.body.classList.remove("show-TopBanner");
        sendInteractionToPersonalize("DISMISSED")
        document.cookie = 'pers-' + variant.ref + '=clicked; max-age=31536000; path=/'
    });
}

When you preview this experience, the qa tool will show a green check mark indicating that it processed all the steps including the decision model and html steps.  Be awared, this could make it more difficult to debug your experiences.  If the cookie does not exist, the experience is added to the page.  If the cookie does not exist, the experience is not added to the page.  There is no UI flicker here because it doesn’t show/hide the experience.  Make sure to wrap your entire javascript block in the cookie check so you don’t get null reference errors if your code tries to read elements from the DOM.

Dev tools showing the cookie set for the experience

This solution helps with performance because it does not require you to search guest session to find a specific event.  However, the cookie sits on the client’s browser.   In this example, I have set the cookie expiration for one year (31536000).  But the experience could display again if the user blocks cookies or they clear their cookies.  It is also device specific.  If the user moves to another device, the experience will display again.  For this reason, it is important to end experiences that are no longer being used so users don’t see experiences with outdated or incorrect information.

Conclusion

Which method you choose to implement will depend on what is best for your use case.  If you want to implement either of these options on the out of the box components, you’ll want to create custom web templates by copy/pasting the html/css/javascript of the out of the box component.  The out of the box components cannot be modified or duplicated.

I started a new Sitecore Personalize project.  The client nonprod and prod environments were freshly spun up.  All fresh and clean.  No offer templates, no experiences, no decision models.  I created the first experience and proceeded to click the preview button to test my experience.  To my surprise the experience did not render, and the QA tool did not display.  What was the problem?  Read on to find out.

It worked with my partner sandbox

I had been testing and doing demos with my partner sandbox account and of course everything worked just fine.  I included the Engage SDK javascript on the pages.  I set the clientKey and pointOfSale attributes correctly.  I created an experience in draft mode.  I previewed the experience on a localhost page.  The QA tool loaded correctly.

Sitecore Personalize showing the QA tool, the web experience and the network tab of dev tools listing the relevant assets

Why didn’t it work from my client environment?

I compared my partner sandbox to the client environment.  I watched the network tab and noticed that the call to https://d1mj578wat5n4o.cloudfront.net/sitecore-engage-v.1.4.0.min.js loaded correctly.  This file makes a call to load https://d35vb5cccm4xzp.cloudfront.net/web-flow-libs/<partnerKey>/web-version.min.js.  This file makes a call to load https://d35vb5cccm4xzp.cloudfront.net/web-flow-libs/<partnerKey>/34/web-lib.min.js.  This file makes a call to load https://d35vb5cccm4xzp.cloudfront.net/qa-tool/bx-qa-tool/bx-qa-tool.js.  After all these files are loaded, the QA tool loads and the experience is rendered in preview mode.

Dev tools showing the required assets to load the QA tool and personalized experience.

In the client environment, the call to https://d1mj578wat5n4o.cloudfront.net/sitecore-engage-v.1.4.0.min.js loaded correctly, but the next call to https://d35vb5cccm4xzp.cloudfront.net/web-flow-libs/<clientKey>/web-version.min.js failed with a 403 forbidden response.

Dev tools showing the 403 error loading web-version.min.js.

I tried to call the url directly and got the same 403 forbidden response.

Browser request to web-version.min.js showing the access denied error.

 The Solution

I spent hours comparing my partner sandbox to the client environment seeing if there was anything that I could change or anything that was different between the two accounts.  I could not find anything useful.  I turned to the Sitecore Slack Community to ask my question.  The answer came from @Derek Fahey.  I had my experience in draft mode.  This was the first experience I was creating in my client’s environment.  He suggested that I start the experience and make it live.  This causes a publish to happen. The 403 was likely caused by not having live content in the web config files. Once I did that, the https://d35vb5cccm4xzp.cloudfront.net/web-flow-libs/<clientKey>/web-version.min.js loaded correctly and I was able to preview the experience on my local site with the QA tool.

Conclusion

When you are setting up Personalize the first time, make sure to start/publish an experience straight away.  Then you pause/complete/delete it.  This will allow you to correctly preview any future experiences even in draft mode without error.

Derek also mentioned that this isn’t a problem in new tenants as they do a soft publish to ensure the config files are updated when the environment is provisioned.

In many places around the world, June is considered Pride Month. We kicked off Pride Month by celebrating the launch of PRISM, Perficient’s newest ERG dedicated to creating safe spaces for understanding, education, and culture focused on respect, recognition, and learning for the LGBT+ community and allies. 

PRIDE Month Realness 

For our first event, we proudly launched our inaugural Perficient Ball, “10 10 10‘s – Celebrating Pride Across the World.” This event was an epic showcase of our diversity and courage, representing our unity around the globe. 

Colleagues around the world celebrate pride in various ways: gathering with friends, attending marches, expressing our freedom, and sharing our support and pride with the community. Historically, the LGBT+ community has sought and created safe spaces, and one of these iconic spaces is the “Ball.” 

In its beginnings, Balls were places where predominantly gay and trans people found moments of joy, embracing their identities to the fullest. In a world where they couldn’t see each other, a Ball was a space to shine, dance, and find love and security, all with glamour, glitter, and energy (think 1991’s Paris Is Burning). Today, Balls are open to the entire queer community and continue to be spaces of celebration and self-expression. 

Our Event 

Embracing this rich tradition, we created an event for our Perficient members around the world to celebrate together, learn, and connect. We witnessed how both the community and allies showcased their pride from their respective corners of the globe. 

During our event, we aimed to crown our “Proudest Perficient PRISM Member.” We had seven finalists, guided by our charismatic host and PRISM co-chair, Avi Fuld. Each finalist shared their experiences through videography, photos, and presentations from vibrant locations such as Guadalajara, Argentina, Chicago, St. Louis, and Atlanta. 

What the judges liked most during the competition was the originality, the music, our cultural diversity, the passion, and the historical touches that the competitors were able to incorporate into their presentations, and we can hear through the competition that everyone must be ready to be “Too glam to give a damn.” 

We had over 50 people attend on Teams throughout the event, who kept the energy high through all participants’ presentations. In the end, the spirit of inclusivity and celebration led us to crown 3 participants as winners, and 4 runner ups. Each finalist brought unique energy, passion, and pride to the event, embodying the very essence of PRISM. By celebrating every participant, we honored the diverse stories and vibrant contributions of our community members, and we were able to donate to even more charities than initially planned. 

Overall, PRISM’s first event as an official ERG was a dazzling success! PRISM is more than an ERG; it’s a community where we celebrate authenticity, inclusivity, and pride. We invite you to join us in creating safe spaces and fostering a culture of respect and learning. Let’s continue to support each other, celebrate our diversity, and shine together. 

Sitecore Personalize uses a combination of experiences, decision models and offers to personalize content.  An experience defines a variant.  The variant is used to create the UI for the experience.  The decision model uses programmables and decision tables to select an offer.  The variant reads data from the offer to populate the UI.  By default, Sitecore Personalize expects the variant to have one user experience and for the decision model to return offers that all use the same offer template.  But what if you want to have different user experiences?  You could have a block of content with a title, image and cta.  You could have another block of content with a title, several icons each with their own block of text.  You could have yet another block of content with the image on the left and the title and description on the right.  Let’s look at some ways to do this in Sitecore Personalize.

Understanding the Pieces

Details of how the pieces of Sitecore Personalize fit together

• Experience: A block of personalized content and the required configurations.  Requires a variant.  Optionally includes page targeting, filtering and decision model.
• Web Experience: Useful for integration into websites
• Full Stack Experience: Useful for integration into websites and mobile apps
• Variant: The user interface for an experience.  Made up of html, css, javascript and api output.
• Html: The html markup for a variant
• Javascript: The javascript required to display a variant on the website
• Css: The css to style the variant
• Api Output: Dynamic data (usually from the decision model) that can be used to populate/modify the html and css
• Page Targeting: Defines which pages the experience will run on
• Filtering: Defines which users will see the experience
• Decision Model: A logical flow chart of business rules that determines the next best offer for the current user.  Made up of input data, decision table, programmables and offers.
• Canvas: The visual design tool for a decision model
• Input Data: Read data from the user, sessions and orders
• Programmables: Server-side javascript used to make decisions about the current user
• Decision Table: A matrix of data values mapped to offers
• Offers: The content that is used to populate the variant
• Offer Template: The field definitions (label and type) used to create offers

Multiple Layouts Option 1

Multiple web experiences, multiple decision models, multiple offer templates.

Visualization of option 1

You would create one experience, decision model and offer template per layout.  If your layouts share the same data fields, you can reuse the offer template.  If your layouts share the same logic, you can reuse the decision model.  In this case you will use page targeting and filtering to help control where and when the experiences will be displayed on your site.  Be aware that this option could have performance impacts as the number of experiences rise.  Sitecore Personalize will check every experience to see if it needs to run for the current page or current user.

Pros: Easy to manage each individual layout.

Cons: The page targeting, filtering, decision models, and offers can get cumbersome and complex to manage.  It is difficult to predict which experience will trigger on a given page for a given user.

Multiple Layouts Option 2

One web experience, one decision model, one offer template.

Visualization of option 2

You would create one web experience with multiple layouts defined in the html.  Use if statements to decide which layout is visible based on a variable in the api.  Include a number field in the offer template that indicates which layout to use.  Add fields to the offer template to support all the different layouts.  Don’t add fields to the offer template that you don’t need and try to reuse fields across layouts by using generic labels.  You might create a help document for content authors to know which fields are used by which layout.  Keep in mind that you cannot reorder fields on an offer template and you can only add new fields at the end of the list.  When you create an offer, all fields from the offer template must be filled out to save the offer (you can use NA on fields not required by the specific layout).

Multiple layouts inside one experience

Pros:  Only one experience to manage.  Only one decision table to manage.

Cons: Having multiple layouts in one experience can get a little confusing to preview.  Creating an offer requires knowledge of how the fields are used in each layout.

Multiple Layouts Option 3

One web experience, one decision model, multiple offer templates.

Visualization of option 3

This is similar to option 2 except that you would create one offer template per layout.  The fields can be labeled specifically how they will be used in a single layout.  This makes it easier for the content authors to create an offer based on the correct offer template for the target layout.  The decision model gets more complicated as you add more layouts.  You add a decision table for each layout/offer template.  You must assign your inputs to each decision table. The content authors are able to assign the correct offer to the correct layout.

One decision model with multiple decision tables

Be aware that this option could have performance impacts as the programmables are evaluated for each decision table on the canvas.

A programmable will run once for each decision table it is linked to

Pros: Only one experience to manage.  Individual offers are easier to manage.

Cons: The decision model is harder to manage as the number of layouts grows.  Each programmable is evaluated once per decision table.

Multiple Layouts Option 4 & 5

One full stack experience, one decision model, one offer template.
One full stack experience, one decision model, multiple offer templates.

These two options are the same as option 3 and 4 except they use a full stack experience instead of a web experience.  This means you will call the personalize api manually.  This can be done either server-side or client-side.  You will use the data returned from the api to populate the UI.

Pros: Complete control of UX.

Cons: You must call the personalize api manually and handle the response to populate the UI.  Requires developers to make the api calls as well as to make changes to the UX.

Conclusion

You can bend the rules of Sitecore Personalize to allow multiple layouts.  Consider the pros and cons of each solution and pick the option that is the easiest to manage while keeping the highest performance for your situation.

Shoutout to Megan Jensen for the fun visualization graphics!