Skip to main content

3 posts tagged with "ios"

View All Tags

· 2 min read
Chris Palmer

Recently we released event-based Tribes, allowing operators to segment their audience by the events which they have performed. This opens up more targeting possiblities including the ability to respond to user interaction in real-time.

To get the most out of event-based Tribes, we needed to update a few aspects of our SDKs. Specifically we've introduced two new features:

  1. Global Events
  2. Event Metadata

Continue reading to learn how these features can help you get the most out of event-based Tribes.

Global Events#

The SDK has always offerred the ability to track events as users perform various actions. However the SDK only allowed events to be tracked at the Experience level. For customers who weren't using mtribes for targeting, this posed a limitation.

import { collections } from "./src/mtspace/example";
// requires an experience to track "item/clicked"let bannerExperience = collections.home.banner;bannerExperience.track("item/clicked");

To overcome this limitation we've introduced Global Events so that events can be tracked outside of an Experience. This can be done by calling Session.track() directly, without needing an Experience first.

import { session } from "./src/mtspace/example";
// ONLY requires the session to track "item/clicked"session.track("item/clicked");

This will hopefully mean a simpler setup for customers who don't require Experiences (i.e. no need to create a container Experience just to track events). For customers who are using Experiences, there is no change and everything will continue to work as normal.

Event Metadata#

The SDK enabled developers to track custom event types, however developers weren't able to provide any contextual information along with the event. For example, if you wanted to track a movie/watched event, you might want to include the title, or the genre of that movie.

videoplayer.track("movie/watched");// title ??// genre ??

To address this limitation of the SDK, we introduced Event Metadata which allows developers to provide 3 metadata pairs when tracking an event:

videoplayer.track("movie/watched", {  pair1: {    key: "title",    value: "Parasite"  },  pair2: {    key: "genre",    value: "Comedy Thriller"  },  pair3: {    key: "language",    value: "Korean"  }});

Event Metadata is particularly useful for event-based Tribes, because events can be filtered by their metadata when building a Tribe. This gives operators more granular control over which events they select for an event-based Tribe.

· 3 min read
Chris Palmer

With the introduction of our Environments feature, all mtribes Spaces are now available in Development, Staging, and Production variants. To complement this, we've made some changes to our SDKs and the Platform API.

Continue reading to learn about the new changes and how to upgrade to the latest SDK and Platform API.

SDK#

You are now required to specify the target environment when initializing a client SDK. To do so, provide the API key associated with the target environment, found on your Space settings page.

If you haven't done so and are using the Browser SDK, an error will be logged and default fallback states will be served. If you're using Android or iOS, you will receive a compiler error.

Note: Regardless of what environment API key you specify, any fallbacks served will always be for the Production environment. Learn more about fallbacks in our SDKs.

To learn more about how to upgrade your code to use the environments feature, see the following guides:

  1. Browser
  2. iOS
  3. Android

Note: Currently, the Roku SDK does not support configuration of the target environment, so it will default to Production.

Collection publishing

You will need to ‘Publish’ any pre-existing Collections in the Staging & Development environments for them to work correctly.

Platform API V2#

The biggest difference between our Platform API V1 and V2 is the addition of the Environment Resource. There have also been some changes to the existing User Resource as users and visitors are now scoped at the environment level.

The Environment Resource lists environments available for your Space (Development, Staging or Production):

GET /v2/spaces/:spaceId/environments

The User resource has been moved to underneath the Environment resource. To manage users belonging to a particular environment, you must specify the API key for that environment in path parameters:

GET /v2/spaces/:spaceId/environments/:envKey/users

Upgrade Steps#

  1. Switch to the Platform API V2.

    Change v1.0 to v2 in the request URL.

    Existing:

    GET https://api.mtribes.com/v1.0/orgs   

    New:

    GET https://api.mtribes.com/v2/orgs
  1. Include the environment keyword when managing users.

    For User Resource requests, include the environment keyword in the path: /environments/{production/development/staging}

    Existing:

    GET https://api.mtribes.com/v1.0/spaces/87930769-ea4c-439c-ba6a-abe9a4559f29/users

    New:

    GET https://api.mtribes.com/v2/spaces/87930769-ea4c-439c-ba6a-abe9a4559f29/environments/production/users
  2. Manage users and visitors in different environments.

    If you wish to manage users on a different environment to production, use either staging or development as the environment keyword in the request path.

    GET https://api.mtribes.com/v2/spaces/87930769-ea4c-439c-ba6a-abe9a4559f29/environments/development/users

    Or:

    GET https://api.mtribes.com/v2/spaces/87930769-ea4c-439c-ba6a-abe9a4559f29/environments/staging/users

Learn more about the Platform API.

End of life#

The Platform API V1 will be deprecated by February 2022. If you still require access to this version of the API, refer to the Platform API Documentation V1.

· 3 min read
Mike Stead

As we've been building and dogfooding our sdks over recent months we've reflected on how to refine the developer experience.

Part of this journey is a healthy obsession with clean and concise APIs with minimal cognitive surface area.

While we don't intent to introduce breaking changes often, being in beta gives us some headroom to improve where we see an opportunity to.

With these points in mind we're introducing a change to our session API across our client SDKs.

What's changed#

Previously when starting an mtribes session you'd call

  • session.identify(userId) for a logged in user
  • session.anonymize() for an anonymous user

We're replacing the above with

  • session.start(options)

When a userId is included in the options then we determine the user to be known and follow the old identify flow.

When no userId is provided then the user is anonymous and we follow the old anonymize flow.

You can find full details in our developer documentation.

Upgrade steps#

JavaScript#

Version v1.0.0-beta.7 of our JavaScript library introduces this change and marks session.identify and session.anonymize as deprecated.

Follow these steps to upgrade.

  1. Upgrade your mtribes CLI

    • osx: brew upgrade mtribes
    • win: scoop update mtribes
  2. Regenerate the integration code: mtribes update

  3. Replace calls to session.anonymize and session.identify with session.start following these examples as a guide.

session.anonymize();// becomessession.start();
session.anonymize(fields);// becomessession.start({ fields });
session.identify(userId);// becomessession.start({ userId });
session.identify(userId, fields);// becomessession.start({ userId, fields });

Android#

Version v1.0.0-alpha.29 of our Android library introduces this change and marks session.identify and session.anonymize as deprecated.

Follow these steps to upgrade.

  1. Upgrade your mtribes CLI

    • osx: brew upgrade mtribes
    • win: scoop update mtribes
  2. Regenerate the integration code: mtribes update

  3. Replace calls to session.anonymize and session.identify with session.start following these examples as a guide.

kotlin#

Mtribes.session.anonymize()// becomesMtribes.session.start()
Mtribes.session.anonymize(fields)// becomesMtribes.session.start(StartOptions(fields = fields))
Mtribes.session.identify(userId)// becomesMtribes.session.start(StartOptions(userId))
Mtribes.session.identify(userId, fields)// becomesMtribes.session.start(StartOptions(userId, fields))

java#

Mtribes.session.anonymize()// becomesMtribes.session.start()
Mtribes.session.anonymize(fields)// becomesMtribes.session.start(new StartOptions(null, fields))
Mtribes.session.identify(userId)// becomesMtribes.session.start(new StartOptions(userId))
Mtribes.session.identify(userId, fields)// becomesMtribes.session.start(new StartOptions(userId, fields))

iOS#

Version 0.2.0 of our iOS library introduces this change and marks session.identify and session.anonymize as deprecated. Follow these steps to upgrade.

  1. Upgrade the library by following these steps.
  2. Replace calls to session.anonymize and session.identify with session.start following these examples as a guide.
Mtribes.session.anonymize()// becomesMtribes.session.start()
Mtribes.session.anonymize(fields: fields)// becomeslet options = StartOptions(fields:fields)Mtribes.session.start(options: options)
Mtribes.session.identify(userId:userId)// becomeslet options = StartOptions(userId: userId)Mtribes.session.start(options: options)
Mtribes.session.identify(userId: userId, fields: fields)// becomeslet options = StartOptions(userId: userId, fields: fields)Mtribes.session.start(options: options)

End-of-life#

The deprecated functions identify and anonymize will continue to work across each SDK until our first major release v1.0.0, at which point they'll be removed.

We recommend upgrading at your next convenient opportunity.