Plan a Web Integration

Combined with helpful tips and tricks, the steps in this document reflect how our internal development teams approach implementations. Follow these steps in the correct order as guidance for planning your Marketing Cloud Personalization web integration.

During the Personalization discovery process, a solution architect works with the Personalization customer to understand the business context for the Personalization web implementation, any web campaign requirements, and the web-channel solution architecture to implement. Ideally, the implementor comes away from the discovery process with a deep understanding of the website's structure and what data is available for collection by Personalization.

The following list details all the tasks the implementation team carries out during this process.

  • Establish the business context and goals of any web campaigns, along with requirements for the associated web templates. For specific technical documentation about Campaigns and Templates, see the Web Templates documentation on this site and About Web Campaigns and Templates on Salesforce Help.
  • Identify the identity attributes necessary for your implementation. Take careful consideration when deciding what identities to use; since identity setup is permanent, it has significant implications for your deployment. Refer to the following documentation for detailed information about how the identity system functions and how you can configure it for use with the web SDK.

Additional considerations:

The site-mapping blueprint is all about planning. A sitemap blueprint is a skeleton for the structure of your sitemap. It serves as a guide for the developer writing the sitemap code and a reference for developers unfamiliar with a particular implementation. In the sitemap blueprint, you define the page types to be mapped, how the platform treats them, what relevant data is available on each page chosen for mapping, and where individual values to be collected are found within the site.

Creating a good sitemap blueprint is the part of the implementation process that is key to developing the data model. Ensure that the decisions made during blueprinting make sense from a technical standpoint. For more information about data modeling, see the Data Modeling documentation.

It's also essential to keep the client's use cases in mind while developing your blueprint to ensure you create a data model capable of supporting those cases. Additionally, create the blueprint document collaboratively; it's crucial to involve both a business user and a technical resource familiar with the product throughout this process.

After the blueprint has the overall sitemap structure in detail, we recommend adding to the blueprint where each piece of data to be collected can be found on the client's website.

Ensure that you call out all identities needed for this implementation in your blueprint. Finally, get your technical resource to validate whether the values for identity attributes are available on the site and/or through ETL and that all of the identity types you are planning to configure will aid your use cases.

You can start the Personalization web integration by deploying the JavaScript web beacon on all pages that you'd like Personalization to monitor. Typically, the team or individual responsible for deploying software to the company website carries out this task.

Validate the JavaScript Beacon deployment, either before or during the sitemap development process. Next, develop the sitemap configuration for all page types and test the sitemap data ingestion to ensure that it meets the anticipated web campaign requirements. For more information on the sitemap development process, see Sitemap Development.

Leveraging a test dataset to hone your sitemap allows you to experiment during the early stages of the implementation process. It helps ensure that any data captured while working on a sitemap does not contaminate the data in your production environment. Any data captured in your production dataset is factored into the catalog structure, campaign targeting logic, and machine learning recipe training. Hence, it is essential to avoid polluting your production dataset with unwanted data elements. Most importantly, editing and revising sitemap code directly in production can lead to incomplete and unvalidated code running live on the client's site.

Creating and using a test dataset is a simple but critical measure to ensure safe sitemap iteration and a pristine production environment. You can create a test dataset by referring to the instructions listed in the Personalization Datasets article on Salesforce Help.

First, Validate the JavaScript Beacon Deployment to check whether the site already has the JavaScript beacon installed. Then, install the Salesforce Interactions SDK Launcher by referring to the Install the Salesforce Interactions SDK Launcher documentation. When using your test dataset and viewing the site in your browser, the option you enable on the Salesforce Interactions SDK Launcher changes based on the presence of the JavaScript beacon. If the beacon is live on the site, enable Force Web SDK URL. If the beacon is not live on the site, enable Inject Web SDK. For more information on each of these scenarios, see Set Up the Visual Editor on Salesforce Help.

Throughout the development process, remember to validate the events sent by your sitemap using all of the methods outlined in the Sitemap Event Validation documentation. Doing so enables you to identify any timing issues, errors, or unexpected behavior caused by your sitemap code as they occur.

If you are capturing any data from a form as part of your sitemap, remember that it is best to collect form entry data upon form submission only. Following this practice makes sure that you only collect data that was truly intended to be submitted by the user. Consequently, this practice also helps enhance the reliability and accuracy of the data since it would have undergone and passed the same validation processes used to collect these values natively on the client site.

Finally, ensure that all identities are configured appropriately according to the blueprint. To know more about configuring identity types and attributes, see Identity Types and Attributes.

For more information on Sitemap development, see:

When your sitemap code appears to be in good shape, review your progress alongside the Best Practices for Data Capture Using Site Mapping. After reviewing these practices and checking that your code works as intended, pass off your sitemap code for the next phase of code review within your organization and edit them based on the feedback you get.

If the client's site already has the beacon corresponding to the production dataset integrated into their site, adding a sitemap code to that dataset immediately makes the implementation live and data collection begin. Ensure that the client is ready for this step before proceeding.

This process involves ensuring that the production dataset is configured in the same way as the test dataset you have been using to ensure everything works as expected.

  • Reproduce catalog setup from the test dataset in the production dataset.
    • The catalog in the production dataset can be maintained throughout the development process to reflect the Catalog as it gets finalized in your test dataset.
  • Paste the completed sitemap code into the production dataset. Make sure you are saving your sitemap code through the web Sitemap Editor accessed via the Visual Editor.
  • Reproduce all recipes and segments created in the test dataset to support your use-cases and/or reporting efforts.
  • Configure any third-party integrations from the test dataset in production.
  • Configure any feeds from the test dataset in production.
  • If development of campaigns and templates began in a test dataset, the following steps are often required.
    • Export templates from the test dataset and import them into production.
    • Reproduce all campaigns created in the test dataset.

As a best practice, complete the sitemap and move it to production before creating any templates or campaigns. Ideally, all of your campaigns and templates are created only one time directly in the production dataset.

Configure and test the web templates required to support the anticipated web campaigns. For guidance, refer to articles in the Campaign Development section of this site and the About Web Campaigns and Templates article on Salesforce Help.

After you have developed your campaigns, debug them using the Web Campaign Debugger. Also, watch the Event API Responses directly in the Network tab of your browser’s developer tools.

If work on campaigns and templates in the production dataset needs to begin before the sitemap is complete, you can create campaigns and templates within your test dataset. However, be mindful of the following.

  • Cloning a dataset does not carry over data, campaigns, or templates.
  • If templates are built on a test dataset, you have to individually export and then import each template from the test dataset into the production dataset before you go live with them.
  • Campaigns built on the test dataset have to be reproduced manually on the production dataset.

Both templates and campaigns rely on the sitemap in some way to function properly. Without a completed sitemap, it can be difficult to develop a template that works long term, considering that the sitemap is still in flux. Recipes and segmentation depend on the proper implementation of the sitemap based on the discovery and blueprinting processes.