Connect with us

FACEBOOK

How PayPal uses Built-in NLP in Messenger

Published

on

Regardless of how good a bot’s UX flow is, people sometimes send inputs that the developer hasn’t accounted for. Unexpected behavior can potentially break the flow of a bot’s experience and lead to customer frustration when the bot responds incorrectly or doesn’t respond at all.

The Messenger Platform’s built-in natural language processing (NLP) feature can be an effective way to handle these types of off-script user behaviors. To show you how this can work, let’s take a look at PayPal’s Messenger bot.

The fintech company recently integrated built-in NLP into its Messenger bot to take advantage of Wit.ai. This allows their bot to process and understand questions and commands from their customers as free-form input, including questions about their accounts, password resets, declined payments, issues with purchases, and requesting refunds.

PAYPAL BOT DESIGN APPROACH

PayPal designed their bot to have a conversational flow while combining features from the Messenger/Wit.ai platforms. Their team used Wit.ai to create a conversational bot to interact with their customers and provide help with their accounts in real time.

“We looked at a number of NLP tools before choosing Wit.ai. The fact that Wit.ai was integrated into Messenger was a big plus, but we also found that Wit.ai provided the right level of customization with an easy to use interface that allowed both technical and non-technical team members to directly contribute to the bot’s success.”
— Principal Product Manager, PayPal

In the example below, the user wants to ‘dispute a charge,’ which is recognized by built-in NLP and passed to the bot as an intent. The bot then recognizes that it is not able to handle this request with an automated response and uses the Messenger Platform’s handover protocol to seamlessly transition the conversation to a PayPal customer support agent. This design helps the team manage handoffs and conversation control without needing to store the handoff/control state for each conversation.

USING NATURAL LANGUAGE PROCESSING

For companies in industries like fintech, it can be difficult to handle free-form user inputs, since there is often not a common vernacular, and there can often be a lot of overlap in how certain terms are used. For example, if a customer send the input “payment” are they referring to the money they sent to a friend or a payment toward an account balance? Traditionally the solution for these cases is to ask a series of questions to narrow down the user’s intent. This can create additional effort and frustration for the customer, so PayPal decided to focus on simple questions and answers that provide a lot of value, while recognizing when it’s best to pass the conversation to a human.

When they built the bot, PayPal’s developers integrated built-in NLP and customized their entities via Wit.ai. This eliminated the need for separate API calls to other NLP services and reduced latency. They also used both the Wit console and the POST/sample API to provide examples of questions the bot might receive from customers, and because the Wit console is user-friendly and doesn’t require technology-specific input, they were able to quickly scale their bot. In addition, PayPal is a global company with users interacting with their bot from many different countries, so having an NLP framework that supports many languages was important for them (click here to see the languages currently supported by built-in NLP).

KEY TAKEAWAYS

PayPal’s developer team focused on simplicity and creating a bot that could respond quickly to customer needs. NLP combined with other Messenger platform tools gives their bot the ability to handle varied customer inquiries while minimizing the effort needed by the customer to complete their request. In addition, utilizing the Wit.ai platform allowed the PayPal product, design, customer support, and engineering teams to work together seamlessly to understand common questions and needs from their audience base so their bot would deliver the desired results.

Messenger Developer Blog

FACEBOOK

Preparing our Partners for iOS 14: Latest Guidance on SKAdNetwork

Published

on

We’re committed to supporting advertisers and publishers through Apple’s requirements for iOS 14. While guidance from Apple remains limited, we are making preparations to help our partners respond to Apple’s latest updates and prepare for when Apple implements additional requirements. We recognize the need for businesses to plan in advance of these changes, and are providing updated guidance as it becomes available.

Today, we’re sharing the latest on our plans to update the Facebook and Audience Network SDKs to add support for the SKAdNetwork API. We expect to provide another update in November and as Apple provides more guidance.

The Facebook SDK

  • We will release an updated version of the Facebook SDK by early Q1 to support the upcoming iOS 14 privacy feature requirements. As previously shared in September, the new version of the Facebook SDK will provide support for Apple’s SKAdNetwork API and conversion value management.

Audience Network SDK

App Install Ads

To support partners’ readiness for Apple’s privacy requirements for early next year, the following changes can be expected for running app install campaigns for iOS 14 users. We are still waiting for clarity from Apple if additional requirements will be version-based (iOS 14.1 or iOS 14.2 release onwards) or date-based (iOS 14.0 starting on a specific date).

  • Account Management
    • We’re updating previously shared guidance to no longer require a dedicated ad account for app install ads for iOS 14. We will support the ability for advertisers to run app install campaigns for iOS 14 users from existing ad accounts. The existing ad accounts can also continue to be used for app install ads for non-iOS 14 users as well as for campaigns using any other objectives.
    • Due to restrictions imposed by the SKAdNetwork API, there will be a limit on how many separate ad accounts can be used to run campaigns for iOS 14 users and we expect to provide additional details in November.
  • Campaign Management
    • We will require advertisers to create standalone app install campaigns for iOS 14 users. If Apple implements date-based requirements, app install campaigns that are currently running that include OS version 14.0 will stop delivering, and will have a path to migrate to standalone iOS 14 campaigns.
    • Due to restrictions imposed by the SKAdNetwork API, there will be limits on the number of iOS 14 campaigns and ad sets that can be active at any given time and we expect to provide additional details in November.
  • Optimization
    • In preparation for Apple’s requirements for early next year, we will support the ability to run app install campaigns optimizing for installs (MAI) and app events (AEO). Value optimization (VO) support is expected in the weeks following Apple’s required implementation.
    • In order to run app install campaigns optimizing for installs, app events or value optimization (VO), apps must be registered to use SKAdNetwork API and have implemented the ConversionValue() bits using the Facebook SDK, a supported Mobile Measurement Partner, or manually within a specific time range (all calls to updateConversionValue happen within 24 hours of install). We will be using install and post-install event data reported from SKAdNetwork API for the purpose of measurement and optimization.
  • Measurement
    • We will support measurement for app install ads optimizing for install (MAI), app events (AEO), and value optimization (VO) for iOS 14 campaigns with some limitations. These changes are the unfortunate result of SKAdNetwork’s limited capabilities.
      • SKAdNetwork uses its own attribution window. Due to the aggregated nature of the data that is provided by the SKAdNetwork API, we will not be able to provide 1d, 7d, or 28d click-through or view-through attribution window breakdowns.
      • Due to data being aggregated at the campaign level, reporting at the ad set and ad levels will be modeled.
      • SKAdNetwork data will not support breakdowns (age, gender, region, placement, etc.) for app install or post-install event metrics.
      • Due to the delay of reports from the SKAdNetwork API, events will be reported based on the time the data is returned through the SKAN API.
  • App Events API
    • Partners who use the App Events API today will be able to continue to use the App Events API. However, support for Apple’s SKAdNetwork will require changes within your app. We will be providing additional implementation details in a future update.
  • Supporting advertisers who work with Mobile Measurement Partners
    • We are partnering with Mobile Measurement Partners (MMPs) to support interoperability of SKAdNetwork through either Facebook or MMP SDKs. This work is ongoing and requires further testing. We will provide an update as the solution is finalized.

We recognize that further details are required to plan for additional requirements created by iOS 14. Like the rest of the industry, we continue to prepare for Apple’s changes and will provide additional updates as Apple provides more guidance, with our next update expected in November.

Previous Updates to Prepare our Partners for iOS 14:

Facebook Developers

Continue Reading

FACEBOOK

How Our Focus on Privacy Impacts Developers

Published

on

Today, we’re sharing some of the changes we’ve made to our privacy program over the past year and examples of the new ways we’re operating to ensure we protect people’s privacy. At Facebook we are committed to building a safer, more sustainable platform to strengthen trust with people and continue to drive long-term value for our developers. Simply put, protecting the privacy of the people who use our products is a responsibility we share with all developers on our platform.

We’ve made changes to put privacy at the core of everything we do. The new Platform Terms and Developer Policies are a starting point to ensure businesses and developers clearly understand their responsibility to safeguard data and respect people’s privacy when using our platform and tools.

We’ve also continued to refine and streamline our App Review process which will ensure consistency for all developers. This includes changes that help developers build business solutions and tools as well as have additional control over the data permissions they request and the ability to remove them when no longer needed.

Finally, we introduced Data Use Checkup, a new annual workflow to drive accountability for all Facebook platform developers. With Data Use Checkup, developers are required to review the permissions they have access to and commit that their API access and data use comply with the Facebook Platform Terms and Developer Policies in order to keep their API access.

In addition to simplifying and clarifying developer responsibilities, we’re also proactively taking action against companies and individuals who abuse our platform. Earlier this month, we filed a lawsuit against two companies that used scraping to engage in an international data harvesting operation, and a few weeks ago we took action against two companies operating fake engagement services.

These improvements are intended to help create a better privacy foundation for developers and we encourage all developers to build experiences using a privacy-first approach, with principles such as data minimization as their guide.

As a reminder, developers will be required to complete Data Use Checkup within the next several months in order to maintain API access. If you have yet to go through Data Use Checkup, you’ll be receiving a Developer Alert triggering an email to your app’s administrators and notification in your App Dashboard, notifying you to complete the process.

To prepare for the process, make sure you’ve updated contact details and app administrator designation for each app within your organization. You can also learn more on the new Platform Initiatives Hub.

We know user privacy is just as important to our developer community as it is to us. Thank you for continuing to partner with us as we build a safer, more sustainable platform.

Facebook Developers

Continue Reading

FACEBOOK

Preparing for Apple’s App Store Data Disclosure Requirements

Published

on

To support our developer and advertising partners with the upcoming iOS 14 App Store data disclosure requirements, we have consolidated previously released public information that explains Facebook’s data collection practices for the Facebook SDK to make it easier for you as you fill out the App Store Connect questionnaire when it’s released.

Facebook SDK

To provide functionality within the Facebook SDK, we may receive and process certain contact, location, identifier, and device information associated with Facebook users and their use of your application. The information we receive depends on what SDK features 3rd party applications use and we have structured the document below according to these features.

App Ads, Facebook Analytics, & App Events

Facebook App Events allow you to measure the performance of your app using Facebook Analytics, measure conversions associated with Facebook ads, and build audiences to acquire new users as well as re-engage existing users. There are a number of different ways your app can use app events to keep track of when people take specific actions such as installing your app or completing a purchase.

With Facebook SDK, there are app events that are automatically logged (app installs, app launches, and in-app purchases) and collected for Facebook Analytics unless you disable automatic event logging. Developers determine what events to send to Facebook from a list of standard events, or via a custom event.

When developers send Facebook custom events, these events could include data types outside of standard events. Developers control sending these events to Facebook either directly via application code or in Events Manager for codeless app events. Developers can review their code and Events Manager to determine which data types they are sending to Facebook. It’s the developer’s responsibility to ensure this is reflected in their application’s privacy policy.

Advanced Matching

Developers may also send us additional user contact information in code, or via the Events Manager. Advanced matching functionality may use the following data, if sent:

  • email address, name, phone number, physical address (city, state or province, zip or postal code and country), gender, and date of birth.

Facebook Login

There are two scenarios for applications that use Facebook Login via the Facebook SDK: Authenticated Sign Up or Sign In, and User Data Access via Permissions. For authentication, a unique, app-specific identifier tied to a user’s Facebook Account enables the user to sign in to your app. For Data Access, a user must explicitly grant your app permission to access data.

Note: Since Facebook Login is part of the Facebook SDK, we may collect other information referenced here when you use Facebook Login, depending on your settings.

Device Information

We may also receive and process the following information if your app is integrated with the Facebook SDK:

  • Device identifiers;
  • Device attributes, such as device model and screen dimensions, CPU core, storage size, SDK version, OS and app versions, and app package name; and
  • Networking information, such as the name of the mobile operator or ISP, language, time zone, and IP address.

Audience Network SDK

We may receive and process the following information when you use the Audience Network SDK to integrate Audience Network ads in your app:

  • Device identifiers;
  • Device attributes, such as device model and screen dimensions, operating system, mediation platform and SDK versions; and
  • Ad performance information, such as impressions, clicks, placement, and viewability.

Facebook Developers

Continue Reading

Trending