Adobe Experience Platform Mobile SDKs – Places

This article is part of the Adobe Experience Platform Mobile SDKs mini-series. It is about tagging your app, more specifically about how to add and use Places in your app.

You can find the overview here.

Places, or points of interest (POIs), can be a very interesting aspect of a mobile app. By definition, mobile apps run on devices that move around a lot, usually with their owners.

It can make a boat load of sense for an app to try and see where it is, or to do specific things in specific places.

So that’s our topic for today.

Places

Places comes with three parts:

• There are a web service, an API and a UI that let you define Places, plus
• an Extension, called Places, which adds geofencing capabilities to your app, plus
• a second Extension, called Places Monitor, adding convenience by handling the OS geofencing interactions and some more.

To cite the documentation

Here are some of the ways you can use Places:

• Send a real time notification when someone enters a POI, “Hey..welcome to the stadium.”
• Analyze foot traffic of your own stores versus your competitor stores.
• Segment an audience based on offline behavior by using audience profiles with location context.
• Target a user with an in-store experience when relevant.

The idea behind all of this is that you create POIs, and that using Places, you can get your app to track when people are close to your POIs, or even trigger things in your app when they enter or exit.

Given that we all walk around with our phones most of the time, that can be pretty powerful.

You have to do a bunch of things to use Places.

Define Places / POIs

First, define Places, or POIs, in the UI.

You can do that by switching to Places in the Experience Cloud, or by directly going to the Places UI.

Once there, use the big, blue “New” button in the top right corner to create POIs.

You can enter Lat/Lon coordinates, or drop a pin on the map. Give your POIs names, and some other data, then save them

You can organise your POIs into “Libraries”, which helps if you have multiple apps with different Places.

In Launch, you can go to the Places Extension configuration, and you can select which Libraries the app should use.

What sort of Places or POIs should you define?

That depends entirely on your business and your app.

Are you a retailer? Define all your shops as POIs. Are you a news outlet with a focus on football? Define all the stadiums. Are you an airline? Define all the airports you serve. And so on.

Add Places to your app

Next, add Places to your app.

You are probably used to this by now: step 1 – add the Extensions to your Launch Property, step 2 – create a Library in Launch, step 3 – publish that Library, step 4 – get the added code from the Production Environment on the Environments page.

That’s it.

If your app handles geofencing notifications from the OS, you should not add the Places Monitor Extension, but if it doesn’t, then Places Monitor is a very convenient to handle those.

Data Elements & Events

Because you added the Places Extension to your Property, you can now create new Data Elements.

For each of those Data Elements, you can chose which POI should be used: the current one (if the device is within the radius), the last entered, or the last exited one.

You can also use a bunch of new Events.

Remember how I wrote that you have to do most things up front, even with the AEP Mobile SDKs, but that some things could be driven from Launch?

Well, here you go!

You can create Rules that fire on POI enter and/or exit, and that do anything, like firing an Analytics call.

The documentation has some examples:

• using Places with Analytics,
• using Places with Target,
• using Places with Push Notifications, and
• using Places with Campaign Standard

The latter two allow you to create geofencing-enabled push or in-app notifications.

The things you can do here are more or less endless. The Mobile Core Extension comes with an Action Type “Send Postback”, which allows you to ping any URL, and to add your POI data to the URL as parameters.

You can use that to trigger some web service, which in turn could drive all sorts of things in your app.

To go back to the examples from the documentation, cited above.

You can send a real time notification when someone enters or exits a POI. Use the Mobile Core Extension, the Analytics Extension plus some backend Mobile Services logic, or the Campaign Standard Extension to create push or in-app notifications.

You can analyse “foot traffic” in your own shop versus others. This works using entered POI and exited POI Events and Analytics tracking.

Segment an audience. You can send POI data to Analytics, and create segments based on whether or which POI(s) visitors have been in.

Target users with an in-store experience. Enrich Target parameters with POI data, ten create Experiences in Target that use that data.

Testing

The article about testing and Project Griffon is next.

For now, you should refer to the comprehensive checklist for testing and validation.

And let me know if you are doing anything cool with Places!