Web or App Integration

Customers can engage in a variety of mobile phone experiences powered by workflows that integrate both web and app vendors. These workflows can manifest in numerous UI components that support getting and displaying customer profiles, along with a wallet and any corresponding incentives. Additionally, these workflows can support data that reflects a customer's progress in a campaign or within the tiers of a loyalty program. Worth noting too is that these integrations can access a customer's historical data as collected in the activity or point audit logs.

Some of the web or app vendors integrating with SessionM provide the customer with opportunities to take actions. For example, purchasing an offer from a reward store, taking a survey, sending events, updating a profile, opting in to a campaign, playing a game, referring a friend, and spending currency with a partner. Note that Mastercard's Digital Redemptions product is another example of a web/app spend experience. This product enables consumers to use points as direct payment when checking out on a merchant's or issuer's rewards website. For more information, see Mastercard Digital Redemptions.

Web or application integrations can work in tandem with an ecommerce integration. Often the ecommerce system is a seamless part of the web or application integration that was done previously. In this way, transactions - which are not handled in this integration path - can be integrated with SessionM. For more information, see the Ecommerce integration path.

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

A vendor integration for the web or for an app handles systems containing data for customers such as their profile, campaign progress, history, and available rewards. Once a system is integrated with SessionM, you can use platform APIs to make real-time communication and transactional calls for a variety of use cases. The following core tasks are critical when implementing either web or app vendor use cases for customers:

  • Creating, retrieving, or updating customer profile along with wallet, status, activity log info, and campaigns
  • Sending and retrieving tags that target customers
  • Sending events to trigger behaviors
  • Retrieving campaigns, including progress for customers and any with opt-in
  • Retrieving, purchasing, and redeeming offers, including those from reward stores

Key Integration Endpoints

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

The diagram below depicts the key endpoints enabling a standard web or app vendor integration:

You can access technical details for 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.

Composition of User IDs for Customers

When sharing customer user IDs with SessionM, avoid identifiers that reflect personal information such as name, social security number, email address, phone number, or biometric data. This is data, or Personally Identifiable Information (PII), that customers should not provide in the process of building customer profiles. Instead, customer should provide external IDs that are both globally unique and non-reversible. In other words, identifiers should not be intelligible via any sort of analysis that determines a pattern or formula.

ID Utilization

Generally speaking, the first step in any integration workflow serving customers is possessing their SessionM ID. If this is not already known, you can retrieve the customer's profile, which contains it. While Core APIs can use external or SessionM IDs, the work facilitated with Connect APIs - getting reward stores, getting offers, getting user point balances - requires the SessionM ID.

Efficient Use of API Calls to Retrieve Data

Critical to any system or data being integrated with SessionM is using the most efficient API call for the use case you are building. Simply put: get only the data you need when you need it. Use endpoints that return only the necessary data, and avoid "heavy" or "super" calls that return too much data, including data not required for the page you are displaying. Responses laden with unnecessary data are returned slowly.

For example, the endpoint to retrieve customer has a variety of parameters to get incentive balances, tier status, reward stores, and offers. Employing this call with all of these parameters set is a heavy call and will return several different kinds of data that is likely better served by being displayed on specific data on specific pages that the customer can navigate to.

Log Activity Data Organization

Some of the data typical of SessionM integrations resides in logs, including the point audit log and the activity log. There is customer timeline data that can be accessed as well.

Allow for pagination of the log file data being returned. Carefully limit the number of records you want to retrieve and display. If you don't, you can impair the system's performance. So you need to find a balance between the number of pages needed to display the data and the number of records being displayed on each page.