Salesforce Certified Marketing Cloud Developer Exam Study Notes

Salesforce Certified Marketing Cloud Developer Exam Guide

The Salesforce Marketing Cloud Developer program is designed for developers who have hands-on experience developing for Marketing Cloud. The audience has proven experience with the administration and configuration of the Marketing Cloud Email application, as demonstrated through successful completion of the Salesforce Certified Marketing Cloud Email Specialist exam. This credential is targeted toward the Marketing Cloud Developer who has experience developing dynamic, personalised marketing assets such as emails, landing pages, and forms leveraging HTML, CSS, and AMPscript. The Salesforce Certified Marketing Cloud Developer is also proficient in SQL and has experience in using Marketing Cloud APIs.

The Salesforce Marketing Cloud Developer candidate has the experience, skills, knowledge, and ability to:

• Configure and set-up data models (data extensions, shared data extensions, Contact model).
• Configure data import.
• Work with customers and platform data (SQL, views, Send Log).
• Write basic SQL, including join statements.
• Create dynamic, personalized marketing assets using various scripting languages.
• Build Marketing Cloud web experience (data forms, custom preference pages).
• Explain subscription management
• Work through and resolve scenarios using REST and SOAP API.
• Invest time in studying the resources listed in this Exam Guide and the additional required study materials provided by Salesforce.

A candidate for this exam is not expected to know MobilePush SDK, Journey Builder SDK, custom components, and how to configure Marketing Cloud Connect.

Quizlets

• https://quizlet.com/406519751/marketing-cloud-developers-cert-test-flash-cards/
• https://quizlet.com/557528512/marketing-cloud-developer-flash-cards/
• https://quizlet.com/405232866/salesforce-marketing-developer-certification-flash-cards/

Blogs / Websites

• Preparing for the Salesforce Marketing Cloud Developer certification
• THE AMPSCRIPT GUIDE
• PREPARE YOUR SFMC DEVELOPER EXAM
• Preparing for the Salesforce Marketing Cloud Developer Exam
• Develop for Marketing Cloud
• Salesforce Certified Marketing Cloud Developer Exam Guide

Exam Outline:

Data Modeling: 14%

• Configure account Contact model in Marketing Cloud
• Given a scenario, differentiate the various types and uses of data extensions in Marketing Cloud
• Describe how Contact Records relate across channels.
• Explain the Contact Delete process.

Programmatic Languages: 35%

• Given a scenario, demonstrate knowledge of AMPscript and SSJS language syntax and functions.
• Implement standard development best practices using Marketing Cloud programming languages.
• Describe how Marketing Cloud handles AMPscript processing.
• Given a customer scenario, determine how to programmatically exclude a subscriber at email sent time.

API: 22%

• Given a scenario, describe API objects, methods, and routes.
• Describe the OAuth authentication flow and how an access token is used in SOAP and REST headers.
• Given a scenario, evaluate the significance of response handling.

Data Management: 22%

• Configure import activity using various file formats within Marketing Cloud.
• Given a scenario, apply SQL to produce the desired results.
• Given a scenario, explain the different ways to extract data from Marketing Cloud.
• Describe SQL best practices for managing data in Marketing Cloud.
• Given a scenario, apply best practices for send logs.
• Given a scenario, describe how data is affected by the Contact delete process.

Security: 7%

• Identify different options to secure data in Marketing Cloud.
• Describe security best practices in Marketing Cloud.

Data Modeling: 14%

Configure account Contact model in Marketing Cloud.

Marketing Cloud Contact Management

• Contact Builder has several tools to help manage contact data for use in building 1:1 relationships:
• Contacts Configuration. Determine how Contact Builder processes imported contact information.
• Data Designer. Define information about your contacts and relate that data directly to the contact record by linking data extensions.
• Data Extensions. Create and manage the data extensions that hold contact information.
• Imports. Create the processes that move contact information into your data extensions.
• Data Sources. Visualize where your contact data originates and assign attributes to those sources.
• A contact is a person you send messages to through any marketing channel. A contact typically appears in the All Contacts section, but a contact record can also appear in other locations.
• A subscriber is a person who opted to receive communications or belongs to a particular channel. A subscriber lives in the individual studios. Subscribers can be imported or created manually and are stored in data extensions.
• Keep in mind that all subscribers are contacts, but not all contacts are subscribers. With email, a contact is somebody you sent emails to, so a subscriber in Email Studio will always be a contact. You can have contacts whom you’ve never sent to who don’t appear in All Contacts.
• A subscriber is only added to All Contacts once something is sent to them.
• Contact information synchronized from Sales or Service Cloud appears in All Contacts, even if you don’t send a message to them.
• Data in Email Studio shows up in Contact Builder, but data in Contact Builder does not show up in Email Studio. In other words, a subscriber in Email Studio will appear in Contact Builder under the All Contacts section, but a contact in Contact Builder won’t automatically appear in Email Studio.

With the contact record, you can view important details about a contact, such as:

• Past interactions, activities, and journeys.
• Relationships.
• Subscription channels.
• Email address and mobile number.

Contact data is managed in Marketing Cloud and Salesforce through Contact Keys, Contact IDs, and Subscriber Keys.

Contact Key: A contact is managed and related through the different channels using a single Contact Key. The Contact Key is a unique identifier that you assign to a contact. If a subscriber is sent an email and the contact wants to be on mobile, the contact is added to the mobile channel by the Contact Key. The Contact Key identifies a contact within an account and ties together the contact, channels, and the relationship. The Contact Key is the same no matter what channel is used to send messages.

Contact ID: The Contact ID is a number Salesforce uses to uniquely identify a contact on the backend. Salesforce uses the Contact ID to identify a contact in various channels.

Subscriber Key: In Email Studio, contacts are identified by the Subscriber Key, which becomes the Contact Key in Contact Builder. The Subscriber Key is the primary key for your subscribers and allows you to identify subscribers with a value that you choose. Use a Subscriber Key to:

• Maintain multiple sets of subscriber attributes for a single email address. For example, if a family shares an email address, you can use a Subscriber Key to uniquely identify each member of the family.
• Include a single email address multiple times on a list. For example, send a separate message for each car a subscriber owns in a single send.

Data Designer is a tool within Contact Builder that is used to define, organize, and relate information about a contact within an account. You can use Data Designer to define attributes about your contacts, create attribute groups that allow you to define relationships, and design populations that allow you to define and use subgroups of contacts.

A contact can contain two types of attributes.

• Profile attributes describe who the contact is. Some of this data is provided by the subscriber, such as gender, state, or interest (do they like hiking or running?).
• Behavioral attributes describe what the contact has done. For example, a contact indicates some related interests or clicks links when reading a newsletter.

Attribute Group: Create an attribute group to connect data to your contacts by establishing their relationship to a contact’s Contact Key.

Populations: If you’re using the most up-to-date Journey Builder functionality, you won’t need to use populations most of the time. Instead, it’s best to save populations for specific use cases where you need to create complex queries, such as if your account uses field-level encryption or when you’re using API Entry Sources in Journey Builder.

If you create populations in your account, limit those populations to three or fewer to improve performance.

Link attribute groups and populations using the Contact Key value.

Attribute Groups and Data Extensions: When you create an attribute group, you give it a name, and you have the ability to link data in Data Designer. Each attribute group includes a data model consisting of data extensions linked to either the contact record or to other data extensions. You can create attribute groups including all relevant data extensions at the same time to ensure that all the necessary data resides in the correct group. After you create a new attribute group, you can create your data model by:

• Creating a new data extension linked to the contact record.
• Linking an existing data extension to the contact record.

Best Practices:

1. Use a Single Contact Key
2. Find Consistent Information to Tie Potential Duplicate Contact Records Together
3. Understand the Difference Between All Subscribers and All Contacts Lists
4. Understand the Contact Record Deletion Process
5. Change ID Number Data Type Before Linking to Contact Key
6. Link Attribute Groups and Populations Using Contact Key When Possible
7. Understand the Differences Between Contact ID and Subscriber ID versus Contact Key and Subscriber Key
8. Limit Populations to Three Entities

Given a scenario, differentiate the various types and uses of data extensions in Marketing Cloud.

There are three types of data extensions in Marketing Cloud.

• Standard data extensions are used for building a custom set of fields.
• Filtered data extensions are used to create a subset/segment from an existing data extension.
• Random data extensions allow you to randomly select subscribers from a source data extension

All data extensions are either sendable or nonsendable.

• Sendable data extensions have a send relationship and map to a subscriber. Contacts are added to All Contacts when you send to them.
• Nonsendable data extensions are reference data, such as the weather, airport codes, orders, product tables, etc. — things you want to use to personalize emails, but not a person you are sending an email to.

Shared Data Extensions: You can share data extensions with other business units by storing them in shared data extension folders. You can configure the data retention policy settings, select who can see what actions are available, set the sharing window, and decide which business units have access to a shared data extension.

Segmentation: Segmentation allows you to create specific criteria or rules and apply the rules to a data extension. Segmentation allows you to take your larger audience and then send targeted and relevant messages to a segment of that audience to ensure that you’re sending the right message to the right subscriber at the right time. When segmenting data, random segments, as well as filtered segments, can be created.

You can create a random data extension, or add the split function, which splits up subscribers from a selected Data Extension and places the subscribers into random Data Extensions in Email Studio. You can create as many as 12 groups at a time and apply filters to segment data on a data extension or data extensions. Filters are typically used to update existing data extensions, as well as create brand new data extensions.

Data Extension Best Practices

• Create data extensions only if you need them and just bring in the data that you need. Views can get messy when you create a lot of data extensions that you don’t need.
• Ensure the data types that you choose match the data you are bringing in. If you have a date field and store it as a text field, that can cause issues with segmentation.
• Make sure that a sendable data extension only has one email address field.
• Filtered data extensions are typically sendable data extensions that have been filtered based off of some sort of criteria.
• Make sure the Subscriber Key is stored as text.

With retention settings, you can select who can see what actions are available, set the sharing window, and select which business units have access to shared data extensions. Consider how long you need to keep your data and configure the retention policy settings when creating the data extension. You can apply a data retention policy to a data extension with less than 100 million records from Contact Builder, but it’s best to plan ahead.

Data that passes the retention limits will be permanently deleted, keeping the record counts in line with your ongoing personalization and segmentation needs. By default, the data extension retention policy deletes unused data extensions after 6 months. The deletion process runs nightly. You cannot remove the configured data retention settings on a data extension once you configure them.

Contact Builder can also bring in data from other Salesforce platforms, such as Sales Cloud and Service Cloud, by using Synchronized Data Sources. Data synchronized into Contact Builder also includes the data schema and relationships previously established in those other platforms.

Contact Builder and Marketing Cloud Connect

You can select and synchronize objects from Salesforce CRM and pull the information into Marketing Cloud using Marketing Cloud Connect. For example, the Northern Trail Outfitters account uses Marketing Cloud Connect and is integrated with a Salesforce Service Cloud account. Marketing Cloud uses Marketing Cloud Connect and Synchronized Data Sources to pull over records from particular objects and put them into a data extension. Once you select the objects, you can select which fields to pull over. You can also set your web records. You can do all records for a time period through a poll schedule, which defines how often Marketing Cloud checks for updates. Remember that syncing objects is important, especially people objects. Every contact or lead synchronized counts as a contact in Contact Builder, even if you’ve never sent them a message.

If you want to synchronize a contact object, you can:

• Select the fields to synchronize.
• Choose which records to pull and use to segment contacts.
• All records
• Records since a certain date
• Records with a particular field type of true or false.
• Set how often the data synchronizes (in minutes or hours).

The order in which you set up objects is important. When you set up synchronized objects, the system starts to create a data model for you. This model ensures the relationships between objects don’t conflict as you integrate additional data sources.

Data sources available for synchronization appear after you integrate your account using Marketing Cloud Connect. After you start a sync, you cannot delete it. You can only pause the sync, but the data extension remains in your account. The synchronized data source appears in your Data Sources when complete.

Data syncing using Marketing Cloud Connect creates a single data extension within your Marketing Cloud account with one column for each field you choose to synchronize. The synchronized data extension uses the name of the synchronized object and adds the suffix Salesforce_n, where n indicates the number of the copy when used in a multi-org environment. For example, if you synchronized the Contact data source, that data source would appear in your Marketing Cloud account as Contact_Salesforce_1.

Access Synchronized Data Sources

Each data source displays both a name and the external API key for the object. Use these names to locate your information and manage your synchronized data extensions. Synchronized Data Sources displays row counts during the initial synchronization and refreshes every 30 seconds.

Segment Synced Data Extensions Across Business Units

Most data extensions need to be segmented to create other audiences for sends. For example, Northern Trail Outfitters shares contact information with a business unit, but their security team doesn’t want the business unit to see all of the contact data. The system segments the data, stores it in a shared folder, then shares it with other business units.

By default, data extensions containing synchronized data exist at the top level of an Enterprise tenant. These data extensions cannot be moved into a shared folder. To segment the data extension, you need to use a query or filter activity that populates the information from a synchronized data source and moves the information into a shared data extension.

You can then share the information with business units in the tenant. You can set permissions on what a business unit is able to see in the data extension. You can also set the sharing rules for the folder itself.

Best Practices

• Use Marketing Cloud Connect to synchronize your Sales Cloud and Service Cloud data with Marketing Cloud.
• Use a query or filter activity to segment synchronized data extensions.

Describe how Contact Records related across channels.

Implement Synchronized Data Sources Best Practices

Follow these best practices to synchronize data into Marketing Cloud Connect using Synchronized Data Sources.

Synchronize Only Necessary Fields

Synchronize only the information necessary for your Marketing Cloud activities, as the process required to synchronize more fields slows performance. We recommend no more than 20 fields per object for optimum performance. If more fields are required, limit the maximum number of fields per object to 250.

Add Fields into Your Synchronized Data Sources from the Original Source

Add fields and update rows in your Sales or Service Cloud source before synchronizing the new fields into Marketing Cloud. Once you complete this process, add the fields within the synchronized data source in Marketing Cloud. This best practice prevents synchronizing fields with empty values, then synchronizing more values. You do not need to refresh or pause your data sources as part of this step.

Delete Fields from Your Marketing Cloud Synchronized Data Sources First

Remove the field from your Marketing Cloud synchronized data source first before the original source. This step prevents you from including out-of-date data in your marketing activities. When you delete a field from the Salesforce source first, that data remains in the Marketing Cloud data source. You receive a warning about the lack of updates, but the most recent version of the synchronized data remains in your account.

Disconnect Your Synchronized Data Sources Connection for Sandbox Instances Only

If you refresh a sandbox instance, disconnect and reconnect your account. Don’t disconnect and reconnect the production account as part of normal business activities.

Pause Your Synchronized Data Sources Connection for Major Changes Only

You can pause your Synchronized Data Sources connection and prevent Marketing Cloud from receiving updated information. Only pause when you make significant data or architecture changes to the Salesforce source. After you complete changes, resume the synchronization process. If the pause lasts longer than 15 days, you must refresh the data source.

Refresh Your Synchronized Data Sources Connection When Necessary

Refreshing a synchronized data source entirely clears Marketing Cloud synchronized data extension and then repopulates the data. Only refresh when not performing any sends or automations using this synchronized data source to avoid performance issues. Any refresh performed in a multi-org environment affects all business units integrated using the same active Salesforce System user. Consider all affected business units before performing the refresh.

Use Synchronized Data Sources in Journey Events

The Marketing Cloud cannot use Synchronized Data Sources as sendable data extensions. Use a query activity to move information from a synchronized data source into a sendable data extension. Update the result of the query activity to ensure that you use the most up-to-date data.

Share Synchronized Data Sources to Business Units

To make synchronized data available at the business-unit level, use a query activity. Move information from a synchronized data source in the parent account into a shared data extension. Create the query activity that moves the data into a new data extension. Next, share that new data extension to the business unit. Update the result of the query activity to ensure that you use the most up-to-date data.

Avoid Breaking the Synchronized Data Sources Synchronization Process

Do not rename or change the API Name for the Sales or Service Cloud object included in the Synchronized Data Sources synchronization process. Renaming prevents the process from occurring.

Do not delete the Sales or Service Cloud object used as part of the synchronization process without first pausing the object in Marketing Cloud. Otherwise, your account could continue to use out-of-date information in your marketing activities.

Do not delete any reference ID field from a synchronized Sales or Service Cloud object included in the Synchronized Data Sources synchronization process. This step corrupts the relationships in your synchronized contact model.

If you delete fields not required by Marketing Cloud as reference IDs in your Sales or Service Cloud objects, Synchronized Data Sources synchronizes changes without errors. If your contact model requires the deleted field as a reference ID, such as an email address or mobile number, you receive an error. The Activity page logs all actions for review and troubleshooting purposes.

Plan Marketing Activities Around Data Refreshes and Large Updates

When a synchronized data source attempts to add, modify, or delete more that 600,000 rows in a minute, Synchronized Data Sources automatically refreshes the data source. This refresh ensures that all fields within that data source update accurately. This refresh process causes the associated synchronized data extension to contain no information until the refresh process completes. The amount of time necessary to complete the refresh process varies depending on the number of records to update. Ensure that you allow enough time between a bulk update of a synchronized data source and any marketing activities using the synchronized data extension. Otherwise, the marketing activity might not access any data during the scheduled performance time.

Understand How Contact Deletion Functions with Synchronized Data Sources

If you delete contacts in Marketing Cloud and a data source synchronizes before the deletion process completes, the process adds a contact record in All Contacts. This record includes an 8–4–4–4–12 character UUID. To prevent this occurrence, delete contact records from Sales or Service Cloud before deleting contacts in Marketing Cloud. You can also turn off the data synchronization process for that data source. These new records include the actual Salesforce ID in the ID field of the synchronized data source. The _contactkey field contains the UUID-style contact key used in All Contacts.

Understand How Formula Fields Update with Synchronized Data Sources

Formula fields contained in Synchronized Data Sources update only when an update for another field on the object occurs. Formula fields do not trigger a change to an object or update last modified date fields. When an update occurs, all synchronized formula fields for that object evaluate and update as necessary. Use performant SOQL in those synchronized formula fields to avoid slow synchronization, as these evaluations take place for every field update.

Filter Synchronized Records to Prevent Duplication of Records

Synchronized Data Sources creates separate contact records for each LeadID, ContactID, UserID, and AccountID synchronized from Sales or Service Cloud. You can filter out records that do not include email addresses to prevent creating duplicate entries for the same contact. Use the Record Collection buttons when creating or modifying a synchronized data source to implement a filter. For example, you can eliminate imported leads without an email address, as you can’t send an email message to them in any case. You can also use Boolean values to filter out records or sync records created after a specified date to include only the records necessary for your activities.

Some users include APEX to populate a Boolean field in Sales Cloud to control which records are synced. For example, APEX can populate a field called Marketable for all records where Email Address is NOT empty. You can then use the Boolean filter in Marketing Cloud to import only those records where Marketable equals True. Editing an already synchronized object causes a refresh for that object.

Explain the Contact Delete process.

Let’s look at the retention settings that are available for your data.

Select On under Retention Setting to ensure that the application deletes all records in the data extension at the same time.

• Delete Options:
• Individual Records. When this option is selected, the data extension is retained, but the individual records inside the data extension are deleted.
• All Records. When this option is selected, the data extension is retained, but all records inside the data extension are deleted.
• All Records and Data Extensions. When this option is selected, the entire data extension and the records inside the data extension are deleted.
• Period Options:
• After. Enter the number of days after the data extension was created to wait before deleting.
• Reset period on import. To extend the retention date following a new import.
• On. Select a specific date to delete.

Using data retention settings in combination with the proper import action (add, update, overwrite, etc.) helps ensure your marketing automations remain useful and up-to-date.

When possible, do not delete contacts. When you delete a contact, you are losing all of the contact’s tracking data and everything about the contact. If you want to remove unengaged subscribers, unsubscribe the contacts from individual channels rather than deleting them. If you want to remove unengaged subscribers, consider moving them to a different journey or data extension. You can also use Einstein Engagement Scoring to promote better engagement.

You can manually delete individual contacts and you can delete lists of contacts, but the Contact Delete feature must be enabled.

We recommend that you keep a log of the contacts deleted to prevent reintroduction. Also, be sure to back up the contact’s preferences so if you ever re-import the contact, you know the channels the contact subscribed and unsubscribed to, which is important for CAN-SPAM compliance. You can delete contacts related to Email Studio from your Marketing Cloud account, but this deletion does not totally remove the contact’s information from Marketing Cloud. Salesforce needs to retain this information to ensure that the contact’s email address does not receive messages from which they unsubscribed.

There is a 14-day default period, which is customizable, where Contact Builder suppresses contact information from showing in channel applications. You can change the suppression if you need to get people out faster. It will only delete subscribers from sendable data extensions, so if you have subscriber data on non-sendable data extensions, you’re going to have to find the contact and delete it. We recommend keep the suppression period as short as possible.

Options to Delete a Contact:

• Contact Deletion using API
• You can delete contacts using Contact ID or Contact Key or List. Refer to the documentation on the REST APIs using the links provided.
• Contact Deletion in UI
• Select a contact from All Contacts and click Delete.
• Contacts have to be set up on a sendable data extension or in a mobile list in order to delete them. You select one of those sources to delete and everyone on the list will be deleted and all the associated contact data will be removed.

Order of Operations When Deleting

When you delete contacts, the contacts are moved from the suppression state to the deletion phase. This creates a hard deletion of the contact from the account and from all sendable data extensions. This cannot be reversed. While the contacts are suppressed, you cannot see specific information about the contacts, you cannot send to them, and you cannot import them. The contacts are removed from queries and are finally deleted. You have to remove subscriber data from non-sendable data extensions on your own.

Once the deletion is completed, you can add the contacts back through data sources. If it’s a user lead or if a contact is injected into a journey, the contact is also added to the All Contacts section.

Sendlog Implications

The sendlog keeps aggregate tracking data. Let’s say you sent to 10 people, then deleted one. Although there is no way to see that you sent to the particular person that was deleted, you’ll still see that you sent to 10 people. So you will still see the aggregate data, but you cannot see the data of the contact you deleted.

Best Practices

• Configure retention settings when creating your data extensions.
• Don’t store all your contact information directly in Marketing Cloud.
• Keep a log of deleted contacts to prevent reintroduction.

Programmatic Languages: 35%

Given a scenario, demonstrate knowledge of AMPscript and SSJS language syntax and functions.

Marketing Cloud offers custom scripting languages to personalize landing pages, create applications, construct cross-channel templates or layouts, and work with messaging functions on the Marketing Cloud platform.

AMPscript

AMPscript is a scripting language that you can embed within HTML emails, text emails, landing pages, SMS messages, and push notifications from MobilePush. Do you want a message to display customized text to the recipient? For example, “Thanks for your purchase, Ted, you earned 1,000 points as a Gold subscriber!” AMPscript is your answer for personalization. Marketing Cloud processes the AMPscript calls at the time of send.

Server-Side JavaScript (SSJS)

Marketing Cloud uses JavaScript code processed by Marketing Cloud servers. Instead of using the browser to render the JavaScript on the client-side computer, Marketing Cloud executes the JavaScript on the server when rendering. While you can duplicate the functionality of AMPscript using SSJS, SSJS doesn’t work with the Document Object Model (DOM) and doesn’t function with exterior libraries. In other words, you can use these functions to modify Marketing Cloud content, but not browser-based things like JavaScript. Instead, use libraries provided by Marketing Cloud to create SSJS that works. These libraries also allow updates to SSJS, while maintaining previous versions, to avoid breaking preexisting code.

Wondering whether to use AMPscript or SSJS? Consider this:

• AMPscript is the preferred language for personalizing message content. It simply and efficiently handles inline personalization or simple IF ELSE statements.
• AMPscript works better than SSJS for use cases where each subscriber needs to see unique content.
• AMPscript has a shorter learning curve than SSJS for users new to scripting languages in general.
• A great number of people already know JavaScript and can immediately apply that knowledge to Marketing Cloud.
• Most users can handle the tasks they need to perform using AMPscript.

We recommend that you exclusively use AMPscript or Platform object server-side JavaScript functions in email messages and reserve your use of Core library server-side JavaScript to landing pages and applications where AMPscript doesn’t provide appropriate functions.

Guide Template Language (GTL)

GTL provides a declarative syntax used for creating personalized, dynamic, data-driven messages, as well as constructing cross-channel templates and layouts. GTL uses the widely adopted Handlebars and Mustache template languages and provides additional functionality, while simplifying how users interact with content and data to help them quickly build personalized Journey messages. GTL works with JSON data sources supplied by script or by a REST API service. Guide can also access specified lists and data extensions within a Marketing Cloud account.

%%_messagecontext%% — Context in which the customer views the email. Resolves to these values:

• SEND — Display the rendered final message for sending to subscriber
• PREVIEW — Display the send preview options available within editor
• VAWP — Display content
• VIEWSENT — Display the non-subscriber link to preview content
• FTAF — Display the rendered Forward To a Friend message
• LANDINGPAGE — Display a landing page or microsite
• VALIDATION — Display information corresponding to the validate option in Marketing Cloud
• LINKRESOLUTION — Display resolved dynamic script at click time
• SMS — Display SMS message content
• SOCIAL — Display Social Forward content
• SITE — Display CloudPage content

%%_IsTestSend%%: Resolves to True if the email job is marked as a Test Send.

%%[

if _isTestSend == false then

… // this code does not run for test sends

endif

]%%

• Exclusion script: an ampscript script used to filter triggered send or user-initiated sends, typically with a suppression list.

Server-Side Javascript methods:

• Add — Invokes the web service API Create method on an API object
• Remove — Invokes the web service API Delete method on an API object
• Update — Invokes the web service API Update method on an API object
• Retrieve — Invokes the web service API Retrieve method on an API object

Server-Side Javascript call parameters:

• Language, ExecutionContextType, ExecutionContentName
• Language parameter, you can specify either JavaScript or AMPscript. The system defaults to JavaScript.
• For ExecutionContextType, you can specify either Get or Post. If no parameter is specified, the system defaults to Get.
• For ExecutionContextName

SSJS Supported Personalization String Tags:

• ctrl:field — References subscriber attribute values, system attribute values, and sendable data extension field values
• crtl:var — References variables created in AMPscript or server-side JavaScript script blocks
• ctrl:eval — Embeds JavaScript expressions as content substitutions

SSJS Supported Personalization String Tags

ctrl:field — References subscriber attribute values, system attribute values, and sendable data extension field values

crtl:var — References variables created in AMPscript or server-side JavaScript script blocks

ctrl:eval — Embeds JavaScript expressions as content substitutions

Retrieve Data Extension using SSJS: var results = DataExtension.Retrieve({Property:”CustomerKey”,SimpleOperator:”equals”,Value:”myDEKey”});

SSJS Core Library Functions: Core library server-side JavaScript functions allow you to use standard JSON and JavaScript functionality to interact with Marketing Cloud. Platform objects can function within landing pages and applications.

SSJS Platform Library Functions: Platform Server-side JavaScript functions allow you to use standard JSON and JavaScript functionality to interact with the Marketing Cloud platform. Platform objects can function within email messages, mobile messages, CloudPages, microsites, and landing pages. Because platform objects exist outside of the core library, you can realize faster performance than with other Server-side JavaScript functions.

Implement standard development best practices using Marketing Cloud programming languages.

Describe how Marketing Cloud handles AMPscript processing.

Given a customer scenario, determine how to programmatically exclude a subscriber at email send time.

API: 22%

Given a scenario, describe API objects, methods, and routes.

Marketing Cloud REST API

• Content Builder: Share marketing content, such as emails, images, text, and other documents.
• Event Notification Service: Receive notifications when certain events occur in Marketing Cloud. You can be notified when customers request password resets, get order confirmations, log in using two-factor authentication, and other events.
• Journey Builder: Create event-driven, responsive campaigns to distribute across any channel (online and offline), at any time and at any frequency.
• GroupConnect Chat Messaging: Send real-time event-based messages to your users in Facebook Messenger and LINE.
• MobileConnect API: Subscribe mobile numbers to a short code using one of three SMS opt-in variations.
• Personalization Builder: Update the data used to provide Einstein recommendations, manage consumer privacy requests, and easily download large reports.
• Transactional Messaging: Send personalized, transactional email messages to your customers.

All new Marketing Cloud technologies implement REST API, so this is an important one to familiarize yourself with. Here are a few important things to note about the Marketing Cloud REST API:

• The REST API uses JSON (JavaScript Object Notation) request and response bodies and resource endpoints to support multi-channel use.
• Most REST calls are synchronous.
• Timeout values are 120 seconds for non-tracking operations and 300 seconds for tracking and data retrieve operations.
• The maximum payload of any call is four megabytes.

SOAP API

As you know, SOAP APIs provide a means for applications on different operating systems, technologies, and languages to communicate using only XML. You can use the Marketing Cloud SOAP API for managing things such as tracking data, subscribers and lists, automations, content, and most other email activities.

• Send Email: Schedule and send emails, identifying message recipients using dynamic, rule-based segmentation of lists, events and profiles.
• Tracking: Retrieve tracking data and use it to create reports and dashboards to see how your customers view and respond to your data.
• Subscribers and lists: Retrieve subscribers for a list or lists for a subscriber.
• Automations: Define an activity using an automation in Automation Studio.
• Triggered Send: Create a triggered email send.

Keep these things in mind when using the Marketing Cloud SOAP API:

• The SOAP API uses SOAP envelopes to pass information between you and Marketing Cloud.
• We recommend a limit of no more than 2000 per minute for SOAP calls.
• Support may request your SOAP envelope to troubleshoot issues.

Describe the OAuth authentication flow and how an access token is used in SOAP and REST headers.

Tenant Endpoints

Marketing Cloud also assigns a unique, system-generated subdomain to each of its tenants. Your subdomain is represented by a 28-character string starting with the letters “mc.” When your subdomain is appended to Marketing Cloud APIs, it creates endpoints that are unique to your tenant. Only your tenant can use your endpoints. No other Marketing Cloud customer can use them for their API requests.

For example, Northern Trail Outfitters’ tenant has this subdomain: mc563885gzs27c5t9-63k636ttgm

These are their endpoints:

REST API endpoint: mc563885gzs27c5t9-63k636ttgm.rest.marketingcloudapis.com

SOAP API endpoint: mc563885gzs27c5t9-63k636ttgm.soap.marketingcloudapis.com

When you create a package in Marketing Cloud to configure API requests that use an access token, you can find your tenant’s endpoints, which contain your subdomain.

1. In Marketing Cloud Setup, click Installed Packages under Apps.
2. Select a package. (We’ll talk more about what this is in the next unit.)
3. On the Details page, find the endpoints under Components.

IP Address Allowlist

Allowlisting is the process of configuring a spam filter to exempt certain email messages from being filtered or rejected. In this case, it refers to configuring your own corporate mail server so that it doesn’t reject or filter the email campaigns you send via Marketing Cloud.

Your servers can interact with Marketing Cloud applications for several different reasons:

• You use Marketing Cloud API to create and send your email and SMS messages.
• You use Marketing Cloud Connect.
• You use Marketing Cloud for Microsoft Dynamics CRM integration.

To properly use the API or the integrations, allowlist Marketing Cloud server IP addresses to allow uninterrupted communication. Because server configurations are unique to each instance, apply them according to your system.

Given a scenario, evaluate the significance of response handling.

Data Management: 22%

Configure import activity using various file formats within Marketing Cloud.

Given a scenario, apply SQL to produce the desired results.

Given a scenario, explain the different ways to extract data from Marketing Cloud.

Describe SQL best practices for managing data in Marketing Cloud.

Given a scenario, apply best practices for send logs.

Use send logging to retain information that can change after a send occurs and can affect reporting. Send logging captures send-time values for reports, extracts, and tracking data.
Use data retention to limit the amount of data stored. Limit data storage to 10 days.
Add 10 or fewer custom fields to the send log.
Minimize the size of the fields used in a send log to the size required for the expected data.
Limit the number of activities concurrently using a data extension. For example, schedule a query activity or report that is reading from the send log to run at a different time than a send that uses the Send Log. You can also use a query activity to move data from an active send log to an archive data extension, as necessary.
Dates added are in UTC-6.

Given a scenario, describe how data is affected by the Contact delete process.

Security: 7%

Marketing Cloud Security

Identify different options to secure data in Marketing Cloud.

• Implement an additional verification method for login using our Multi-Factor Authentication (MFA) system, which includes:.
• The Salesforce Authenticator mobile app
• Security keys that support U2F or WebAuthn, such as Yubico’s YubiKey or Google’s Titan Security Key
• Time-based one-time passcode (TOTP) authentication apps, like Google Authenticator, Microsoft Authenticator, or Authy
• Adhere to strict password requirements for length, characters, and expiration.
• Marketing Cloud admins can assign roles and permissions to individuals for more granular control of access and activities, so work with your Marketing Cloud admin to fine-tune these settings and secure your account.
• As a Marketing Cloud developer, you need to know two important passwords.
• Your account password
• The FTP password for your Marketing Cloud account
• It’s also a good idea to change these passwords regularly (no less than every 90 days) to keep your account secure. And not just any password will do. Create a strong, unique password with:
• Eight or more characters
• Mix of letters and numbers
• Mix of uppercase and lowercase
• Special characters
• Cloud allows third-party, single sign-on (SSO) authentication via SAML 2.0. You can use Salesforce federated authentication or another service, depending on your security needs.
• If you want to encrypt data within your account at rest, you can do just that with Data at Rest Encryption. This solution helps you encrypt data without modifying any existing code and protects against a variety of scenarios, including stolen physical media. In other words, if someone gets their hands on the drive that contains your data, Data at Rest Encryption prevents them from decrypting and accessing the data. This feature is transparent to Marketing Cloud and does not impact any application-level features.
• These features store data in different locations, which prevents Data at Rest Encryption from implementing that data.
• Predictive Intelligence
• Audience Builder
• Social Studio

Marketing Cloud requires secure connections for API calls and SFTP interaction.

Part of keeping your Marketing Cloud account secure is knowing who is performing what actions in your account. After you assign the proper roles and permissions to your account users, any Marketing Cloud Security Administrator can track user actions using the Audit Trail feature. The basic version of Audit Trail is available to all Marketing Cloud accounts and provides 30 days of information for all users in your account.

• User authentication
• IP addresses
• Changes to users, roles, and user permissions
• Changes to Security Settings, such as logins, password changes, and logouts

There is also an advanced version of Audit Trail which captures changes to user agents, session IDs, and business units — plus, changes to content and data for Email Studio, CloudPages, MobilePush, and MobileConnect.

In Marketing Cloud, click Setup and expand the Data Management section to find the Key Management page. This page is where you create and manage your keys. You can create several different types of keys, depending on your needs. Let’s review.

• Asymmetric keys require you to upload a certificate to create the key. These keys help you encrypt and decrypt data and digitally sign email messages.
• Symmetric keys require you to create a passphrase for use with the key. This key value requires 32 hexadecimal characters. These keys help you encrypt and decrypt data and digitally sign email messages.
• Initialization vector keys allow you to specify the 16-bit value yourself, or you can let Key Management create the values for you. Use this key to enable your field level encryption implementations.
• Salt keys use a hex value longer than 8 bits. The encryption uses random bits with a password or passphrase to generate JWTs for custom Journey Builder activities.
• SSH keys allow SFTP authentication and also require an uploaded certificate.
• SSO Metadata keys allow you to integrate a single sign-on authentication for Marketing Cloud. You can only create this key if your account is enabled for SSO authentication.

Example: Encrypt and Decrypt Data with AMPscript

The first script encrypts the value ExampleDate with the provided external keys, and the second script decrypts that data.

%%[
     SET @encData=EncryptSymmetric("ExampleData", "AES", "passwordExternalKey", @null, "saltExternalKey", @null, "IVExternalKey", @null)
     SET @clearData=DecryptSymmetric(@encData, "AES", "passwordExternalKey", @null, "saltExternalKey", @null, "IVExternalKey", @null)
]%%

You can also encrypt and decrypt data for file transfer activities in Automation Studio. Specify the key as part of the file transfer activity from the Marketing Cloud Safehouse location to an FTP Location.

Encode Your JWTs

You can also use salt keys to encode JSON Web Token (JWT) information in a Journey Builder activity. The JWT validates the identity of API calls to your custom activities. Use a JWT for activities that are retrieving sensitive data or performing sensitive actions. In this example, the sample code uses a JWT value and a salt key for the execute, save, validate, and publish activities.

Implement SSO for Your Marketing Cloud Account

Lastly, any single sign-on integration requires an SSO metadata key. The information for this key changes depending on the provider used to create your integration, but you need these values to complete the process.

• SAML metadata
• Fetch data from URL (generated automatically from your provider’s specified URL)
• Provider certificate
• Entity ID
• Name ID Format
• Single Logout Service Location and Binding (determined by your provider)

Create only the keys you need to accomplish your activities and store them securely — like any other security situation, it’s not a good idea to leave keys lying around. Next, let’s take a look at the best ways to keep your web and landing pages secure.

Marketing Cloud handles more than just messages — web pages allow subscribers to submit information, subscribe to communications, or view messages outside of their email client. To ensure the safest experience, we recommend using SSL certificates to secure web-based communications. These certificates can secure:

• CloudPage URLs
• Landing pages in your account
• Links included in email messages from Email Studio
• Portfolio content

Plus, SSL certificates add an encryption layer to web traffic and help prevent external parties from intercepting sensitive information. Whew! That’s a relief.

Need a certificate? Well, you can purchase your own certificates or you can allow Marketing Cloud to manage those purchases for you. If your certificates are purchased through Marketing Cloud, you can use them to secure both pages and content. Plus, Marketing Cloud manages and renews the certificates with no additional cost. If you purchase your own certificates, you can only use your certificates to secure pages (not images).

We recommend using certificates that are valid for a year or less. Why? You guessed it: They’re more secure.

When you use CloudPages or API integrations to capture subscriber information, it’s important that you handle it with trust and security in mind. We’re here to help. Check out these tips to help you secure your form data. (And remember, these aren’t the only security factors you should consider, but they’re a good place to start in Marketing Cloud.)

• If you include query strings in your pages, don’t pass SubscriberID, SubscriberKey, or ContactKey values in the clear. Also, use encryption and not Base64 or StringtoHex encoding to pass values from fields. Encoding can be easily decoded, as opposed to attempting decryption.
• Any processing and validation of fields should occur on the server side. We also recommend using two or more query string parameters to verify that the same subscriber is interacting with the page before presenting any data.
• Any application pages you create should require authentication. We recommend using the AMPscript MicrositeURL function to encrypt query string parameters.
• Any non-authenticated or non-application public landing pages should include a global IF/THEN clause that checks for empty required parameters. This step prevents any processing when somebody tries to access the page directly, instead of through your assigned flow.
• Enable security headers in your pages using this Server-Side JavaScript sample.

Example: Enable Security Headers for a Web Page

<script runat=server>
   Platform.Response.SetResponseHeader("Strict-Transport-Security","max-age=200");
   Platform.Response.SetResponseHeader("X-XSS-Protection","1; mode=block");
   Platform.Response.SetResponseHeader("X-Frame-Options","Deny");
   Platform.Response.SetResponseHeader("X-Content-Type-Options","nosniff");
   Platform.Response.SetResponseHeader("Referrer-Policy","strict-origin-when-cross-origin");
   Platform.Response.SetResponseHeader("Content-Security-Policy","default-src 'self'");
</script>

This example helps prevent common web form issues, such as cross-site scripting or SQL injections.

Describe security best practices in Marketing Cloud.

No matter how you choose to integrate your apps or external systems with Marketing Cloud, there are some guidelines you should follow to keep your data safe. The best practices we cover in this unit help you avoid common security risks like cross-site scripting, sensitive data exposure, HTML injection, and others. Let’s take a closer look at these potential threats.

Cross-Site Request Forgery

This practice tricks an authenticated user into performing an unwanted action on a vulnerable server.

HTML Injection

This attack puts HTML on a vulnerable website, such as an iframe that displays a different page than intended.

Cross-Site Scripting

An attacker uses Javascript on a vulnerable domain and gets a user to click on a malicious link. The browser executes the Javascript and, well, bad things happen.

Arbitrary Redirects

This attack involves a user clicking on what appears to be a typical server URL, but the link sends them to a malicious site.

Remote Code Execution

This attack finds vulnerabilities in target servers and executes input data.

Good news: even though these are some pretty scary security threats, there are things you can do to protect your data. Let’s review some data security best practices.

Data Security Best Practices

Limit Permissions

Whenever you create OAuth access tokens, make sure they are valid only for the necessary tasks. After all, if your neighbor needed something out of your garage, would you give them keys to the entire house? In other words, assign only the necessary permissions to the tokens and the installed package.

Secure Your Tokens

When you store your token values, keep only the refresh token on your external server. Request a new access token when you need one, and only store that value in memory. These tokens need to receive the same security and priority as Salesforce account credentials.

Use Up-to-Date TLS

Make sure your external web servers use an up-to-date TLS configuration, and enforce TLS in your requests to Marketing Cloud APIs. Your access token should only appear in the authorization header.

Review Error Messages

Of course, your error messages should be a little more descriptive than ERROR: #12345. But don’t give away everything in the error message either. Make sure that you don’t include stack traces and debug logs in your error message to prevent attackers from using that information against you.

Create Secure Sessions

Make sure your sessions use secure procedures to create, manage, and end work for authorized users. Rotate session IDs to make sure attackers can’t keep and maintain those values for access. Make sure your integration also verifies user session and permission levels before granting access to restricted data or functions. Keep your functions on a need-to-know basis. And use tenant-specific endpoints whenever available to ensure your requests use the most secure connections possible.

Store Sensitive Info Properly

Store all sensitive information on your own system using your platform’s secure storage best practices. Why store sensitive information — such as passwords, credit card numbers, and Social Security numbers — securely on your own system? Because that information should never be stored on Marketing Cloud servers!

Patch All Important Software and Hardware

Avoid remote code execution problems by patching vulnerabilities on services listening on web server ports, updating software packages, and executing deserialized user data cautiously.

Feeling more secure now? Security is an ongoing concern, and you should regularly reevaluate your security needs. This information gives you a strong foundation for your efforts, though. Nice work!