Third-Party Integration

Third-party platforms are critical to integrations with the SessionM Platform. Generally, these integrations represent specialty platforms. They are less common and fall outside of the more standard set of components such as POS, ecommerce, websites, and apps. Often, too, there is minimal alignment for data sharing between the SessionM data cloud and their own data warehouse.

These third-party integrations ensure a newly connected platform can support activities that transpire bidirectionally: partners accessing SessionM API endpoints, or, SessionM sending webhooks and custom files to partners. Often, SessionM provides partners with the data they will seek and retrieve. One common dynamic is that partners need to trigger activities that require SessionM. The examples are plentiful: customer taking a survey, playing a game, or referring a friend - just to name a few.

Regardless of the activity or partner, the primary focus for SessionM integrations is on non-transactional activities.These are typically a mix of external systems deployed in a variety of combinations, and they fall under one of two functional categories:

• Activity tracking

• Data synching

All of the external systems shown in the table below can be understood by their function - tracking or synching:

External System Type	System Function	Activity Enabled by Integration
Messaging	Data synching	Client pulls up-to-date customer wallet so they can add in customer's active offers. This data can be used as information that populates personalized email templates.
Gamification/Experience	Activity tracking	Client sends events to SessionM - ones that show customer engaged in games and other experiences such as quizzes, polls, and surveys. These can all be important parts of an experience platform.
Wallet Validation	Activity tracking	Client verifies customer is eligible for campaign, having confirmed the customer is real and reviewed the campaigns they are eligible for.
Survey Vendor	Activity tracking, Data synching	Customer engages in triggered activity, making a transaction. This event ensures SessionM is notified to give customer a survey, along with any supporting details. In this activity, SessionM must perform two steps: one, notifying third-party vendor that customer made transaction, so they can send the customer the survey; two, once the customer completes survey, notifying the third-party vendor that they can award customer whatever outcome has been promised, such as a monetary discount or points. Survey vendor integration combines activity tracking and data synching. SessionM synchs data with activity, providing relevant information on the customer - say, email and a favorite store. This then combines with an indication that a transaction was completed. In effect, SessionM tracks activity that supports both parts of the customer experience - ensuring that the customer gets a survey and then completes it.
Refer a Friend	Activity tracking/Data synching	Customers can refer other customers (friends) to join a loyalty program, often by making a purchase. When they do, the third-party system triggers SessionM to evaluate the event and award the corresponding outcome to the referer and/or the referee. Once the customers are credited with the awarded outcome, SessionM triggers a webhook to notify the third-party system of the outcome via their event API. This integration requires a combination of activity tracking and data synching. When SessionM awards the outcome based on a tracked activity, it must also include the relevant customer data in the event message that properly identifies the customers, both referrer and referee.
Write Review	Activity tracking	Customer writes review and the third-party vendor that is tracking that activity then tells SessionM that the customer completed the review or left a comment. This completion of a non-transactional action (a custom event) is a trigger that prompts the third-party vendor or app to notify SessionM to credit the customer with whatever outcome the journey provides. For example, if a customer leaves a review for 3 different products, they are awarded 50 bonus points. This journey must be built to notify SessionM that the review has been written and that they can reward the customer.

Worth noting are a couple of special cases that fall outside of third-party integrations and can be implemented with help from your SessionM team:

• Integration needs a custom component such as a lamda or a middleware transformation layer.

• SessionM may need to pipe data on a daily basis. In this scenario, SessionM needs to sync profiles with them or send them tier information.

The integration under discussion in this topic is highlighted in the image below.

A third-party integration connects an external system to SessionM and generally enables either activity tracking or data synching operations. Once a system is integrated with SessionM, you can use platform APIs as well as webhooks and data exports to make real-time calls for the communications and transactions required for a variety of use cases. The following core tasks are critical when implementing third-party use cases:

• Sending custom events for customer participation in games or referrals
• Using messaging webhooks to send activity completion status, profile data, or referrals.
• Exporting CSV data files supporting GDPR privacy requests, loyalty profiles, data extracts (dumps) or customer attributes for SM Sync ingestion.

Key Integration Endpoints

While this topic does focus on the standard aspects of a third-party integration, each implementation can contain specific transaction data points specific to business, or vertical, needs.

The diagram below depicts the key endpoints enabling a third-party integration focused on either activity tracking or data synching:

You can access technical details for the endpoints featured in this graphic using the links below:

Integration Best Practices

As you move forward with your integration, bear in mind several best practices that can help ensure a successful SessionM implementation.

Data Synching

Consider the following best practices that pertain to data synching:

• Keep data synching to a minimum. Less is more, unless you must pipe the data.

• Just because SessionM has all of the profile data, it doesn't mean all of it should be sent to third-party vendors.

• Determine the correct usage for your data and the associated use cases; then synch the relevant data to support those use cases.

• Consider this question: How do you want to trigger data? Be careful if you are doing profile synching. Try to avoid excessive data traffic and processing by identifying the necessary actions that warrant triggering a synchronization. Just because the profile was updated doesn't mean it needs to be synched with a profile; the data updates may be irrelevant. For example, if your are only synching email and name but there is a change to the customer's favorite ice cream flavor, no synch is needed.

• Use data policies to be strategic about what changes in a profile require a synch. For more information, contact your SessionM team to discuss having them set up the appropriate data policies.

Activity Tracking

Consider the following best practices that pertain to activity tracking:

• Depending on how many events your are sending, the throughput and volume to have the events process synchronously will compromise performance. So, if you don't need responses that show the output from events associated with campaign progress, use asynch events. Contact your SessionM team to discuss configurations that can make event processing asynchronous.
  

• If you are sending both single and multiple events to the Event API, SessionM recoomends capping each call at 200 events.

• Note that there are two differnent Event APIs for this work: V1 for single events and V2 for multiple events.