Azetone v5

Documentation

Welcome to Azetone v5 Dashboard!

Version5 of Azetone’s Dashboard is our latest control panel built on top of our next generation iOS and

Android SDKs (code-named “Foundation”). We have built this new generation with scalability and

expandability at the core. It means that we have the ability to make major changes and add new major

features to the dashboard without requiring you to change or update our SDKs in your Apps every time.

Enjoy our latest breakthrough features and stay tuned for a regular roll-out of new capabilities!

Please note that additional technical details can be found on our online documentation platform at

http://docs.azetone.com

Account Preferences

As soon as you create an account on Azetone’s Dashboard, you will be asked to enter your usual contact

detail including an email and password and to create and App project. Both can be accessed and

modified through the Settings menu on the upper right-hand side of your screen.

Via My Account, you can access and modify all of your account information as well as your password via

the first 2 tabs. You will also find a history of your connections to the Dashboard in the last tab. If you

have a role as Admin or Super Admin for your company, you will have the ability to create and manage

users through the third tab.

Azetone’s Dashboard provides up to 4 different roles for Dashboard users.

1. SuperAdmin: If you were the one creating the account on our Dashboard or have been

appointed by your Azetone’s account manager as the lead for your company, you will be

assigned a “Super Admin” role. This role (there is only one for each account) has all the

privileges for managing the Apps and the services within the Dashboard and can create, change,

promote or demote and revoke users.

2. Admin: The SuperAdmin has the ability to create Admin roles which have virtually similar

privileges to the SuperAdmin. Admins can also in turn create, manage and revoke other users

except the SuperAdmin.

3. Editor: The Editor role provides a user with full capability in the Dashboard for both creating

heatmaps, A/B tests and personalizations (provided these services have been subscribed to by

an Admin user). The editor can also view all reports but can’t manage other users

4. Reader: The Reader, as the name suggests, can access and view any report of existing heatmaps,

A/B tests or personalizations but don’t have the capacity to create new heatmaps or variants.

They also can’t manage other users.

For more advanced security, we also offer IP Tracking (see Dashboard Connections tab) and for ultimate

security you can request to activate our IP whitelisting capabilities. For more info on this premium

feature, please contact support@azetone.com

App Settings

Via “My Apps” you can create new Application projects and switch to existing Apps. This can be done

very easily through the “Create an App” of the selector displayed below.

SDK Setup and Configuration

Once your SDK has been integrated into your App, you will have the ability to control the activation of

the different SDK functionalities by simply switching on or off the modules you want to operate. While

even with all modules activated, the SDK will create zero perceivable impact on App performance, this

configuration panel allows to activate the features you need only when you need them and limit

memory, bandwidth and data consumption to the minimum.

To access this control panel, selection “Application” in the left menu and then the SDK Configuration

tab.

The A/B Testing section controls both A/B Testing and Personalization functions in the SDK and are

divided into 2 controls. The first switch (SDK Feature) enables or disables the handling and tracking of

variants (both visual and universal) within the App. The second (Visual Editor Mode) activates or

deactivates the ability to connect the App in Admin mode to our Dashboard’s Visual Editor capability to

create new visual A/B Tests

The Heatmaps section controls our Heatmaps and UX Analytics functionnality. When SDK feature is

activated this will collect and send gesture and general UX analytics data to our servers. When

Heatmaps mode is activated, the Dashboard’s Heatmaps Admin mode will automatically collect current

app screenshots to overlay heatmaps onto. Please note that data for heatmaps are collected and stored

(provided Heatmaps SDK Feature is On) even when screenshots have not been uploaded on the

Dashboard. As soon as they are, heatmaps will appear instantly based on existing user data.

Event Management with Event Tracker and Event Getter

The Azetone platform allows you to manage two major types of dynamic information exchange between

our servers and your Mobile Apps:

- First of all with our Event Tracker, you can collect particular events in your application to reuse

them on our servers (for example as user segmentation criteria or as objectives in your A/B

tests). it will be necessary to tag these events in the application and then set them in the

Dashboard.

- And with our Event Getter, you can inject into your application information for example to apply

variants of test or customization at the (first) launch of your application

-

These event management are important because they make the most of the power of the Azetone

platform.

The Event tracker makes it possible to enrich the segmentations made with the Profile Builder

with information specific to your application but also to remount synchronization keys (for

example identifiers-possibly encrypted to guarantee total confidentiality) to import by the

following entire segments of your CRM or DMP solution.

Event Getter allows you to go beyond the standard way of operating for the Azetone SDKs.

Indeed, to guarantee an absolute minimal impact on the performance of your application, our

SDK works by default in asynchronous mode and in the background. The SDK is therefore always

pulling data from our servers, for example by requesting variations when processing times and

bandwidth allow. The Event Getter allows you to use the Azetone SDK in "push" mode, i.e. to

inject data into the application and process this data in real-time.

Event Tracker

The Azetone Dashboard allows you to configure events tagged and reported via Event Tracker.

In the "Tracker" section, you can find the list of all events tagged in your code. It is not necessary for the

developer to do any processing or configuration of these events in the App itself. It will be at the

Dashboard level that you will indicate the type of data reported for each event. This is done to simplify

the integration of the tracker into the code of your App.

Event Getter

Through our Event Getter, you have the ability to push data into your application that will be processed

in immediately, without having to wait for the Azetone SDK to put this info in a cache and then serve

these elements to your App. This allows you to work in a synchronous mode ("push mode") between our

servers and your App and get a data feed or apply a variation almost instantly to your application.

The typical use case for our Event Getter is to apply an A/B testing variant to new users, including users

who have just installed the application and as early as the very first screen of your App. Our front-end

servers respond instantly to any request from an Event Getter and will push on-the-fly a variation to all

users involved in the test. A "time-out" can be programmed to guarantee that in every case a maximum

waiting time will be applicable to the user before defaulting to the standard view of the App.

Defining your user profiles with Profile Builder

While you are certainly eager to look at your Heatmaps or to start your first A/B Test, we recommend

you spend first some time with our Profile Builder. This tool will harness the incredible wealth of

customer data collected by Mobile Apps and mix it with other sources of customer data to offer you the

customer segments or profiles that matter most and are the most relevant for your business.

You can then use these profiles to analyze your UX analytics and Heatmaps, to target A/B tests or even

to dynamically personalize your App based on user segment.

Profiles can be defined with different types of criteria:

1. Leveraging criteria that are directly collected by our SDK: These are mostly system events or App

events like:

o Device Category including Platform (e.g. iOS, Android), Device type (e.g. iPhone, iPad,

iPod…), Smartphone model (e.g. iPhone 5, 6, 6s, 7…), country, App version, Datapack ID

etc…

o Usage Category including number of App launches (total or per period), date of first

launch, date of last launch, etc…

2. Using our Event Tracker: Our Event Tracker enables you to pass any type of data from your App

over to our server Databases. Each of these new data fields can then be used as additional

criteria for segmenting your users (this can be a user ID, a user info such as gender, age etc… or

any other user data or action)

3. Using imported segments via API or direct import. Our Profile Builder has the unique ability to

synchronize with external data sources. It can hook up natively to third-party partner solutions

such as push notification solutions like Accengage, Batch, FollowAnalytics, Tealium and several

aothers or import entire CRM or DMP segments based on a defined unique User ID (email,

phone, userID, device ID…) which can be matched to an ID collected via our event tracker

4. Calculated segments are yet another source of segments. They can be the result of users who

were exposed to or have converted on specific variations (A/B Testing or Personalization) or

they can also be “Random Profiles” to provide for a control sample for instance when applying

personalization to a vast majority of your audience.

5. Last but not least, Grouped Profiles can be used to group or combine any type of existing profile

with standard operators such as AND, OR or NOT. This will give you ultimate flexibility in how

you would like to precisely define your profiles and use them within Azetone’s platform.

6. A random profile can also be created, which makes it possible to isolate a control population

which will never be subject to any personalization or A/B test.

Tip: To create a profile with your test devices (smartphones, tablets ...), the easiest way is to use the unique identifier generated by the Azetone SDK. Called "Datapack ID", it can be accessed directly in the App by activating the Azetone Admin mode (via a quintuple double or triple-tap depending on whether you are on iOS or Android). The Datapack ID is located at the top of the pop-up menu and these IDs can be entered in the Profile Builder to form a test profile via the criteria in the "Device" category .

Once these profiles are defined, they can be either “set in stone” and stay as they are with their initial

users (set profile as “locked”) or evolve over time depending on whether new users match or not the

criteria you defined (set profile as “auto”).

Note that a profile can be defined with multiple criteria and that each of these criteria will be treated by

default with an AND relationship (except with Grouped Profiles).

Tip: Please note that the ranking of your profiles has its importance! If a user belongs to different profiles and if he/she is included in an A/B test triggered on the highest ranking profile, he/she will be automatically excluded from an A/B test applied on a lower ranking profile(s) FYI each new profile created will be added by default at the end of the list of profiles but you can shuffle the list of profiles by using the up and down arrows at the right of each profile name.

You can get further details on how a profile was set up and how it evolves over time by clicking on the

icon

Analyze your App User Experience (Heatmaps)

Once you have created your profiles, you will be able to visualize every report and target any action

across Azetone’s Dashboard based on these segments. This will provide you with unparalleled insights

into how users are using your app and how you can further improve and personalize their Mobile user

Experience.

With UX Analytics, you gain a very comprehensive view of how users are interacting with your App.

There are 2 types of reports you can look at:

- The Overall Data View will deliver key data points on the overall usage of your App by user

profile, by platform, by device, by time period and by type of gesture

- The App Heatmaps (for iOS or for Android depending on your App) will visually display each

gesture completed by users on each view of your App. Again these Heatmaps can be filtered by

multiple criteria for a deeper understanding of your user experience

Overall Data View

As soon as Azetone’s SDK is successfully integrated into your App, our servers will start collecting data

points for each session, view and gesture from every user of your App. The number of high level metrics

will be displayed in the first tables. This is a great way to identify at a glance how and where users are

interacting the most with your App.

The following charts and tables are providing further insight about how users are interacting. Which

gestures they are performing most or least or the average number of interactions per user in each

profile.

These charts and tables are just a high level analysis of the data collected by Azetone’s SDK and just the

very tip of the iceberg of insights that can be obtained with Azetone’s platform.

If you have subscribed an Enterprise license, you will have access to Azetone’s entire UX analytics

dataset for your App(s). Azetone and its partners can also provide you with a customized Mobile UX

Analysis Report based on any dimension and segment you may require.

You can check out a demo report here: https://app.powerbi.com/. Please use the following id and

password to connect: demo@azetone.onmicrosoft.com and password: Aztn062014

Click then on “Report” and “Demo Dataset”

For applicable Terms and Conditions, please contact your Azetone representative or Azetone’s sales at

welcome@azetone.com

Viewing your App Heatmaps (iOS and Android)

As soon as you have successfully integrated Azetone’s SDK, each of your users’ gestures will be captured

and stored on our servers. However for a rendering of these results, you will have to activate at least

once our Heatmap Admin Mode. This can be done by clicking on the button

Once clicked, a dialog box will open displaying a one-time password. This password will be re-generated

for every Dashboard session. The password is meant to be entered on your device after activating the

Heatmap mode with Azetone’s special Admin gesture.

On your iOS device, Admin mode is activated but tapping 5 times with 2 fingers (quintuple double-tap)

on your App screen On Android tapping 5 times with 3 fingers (and not 2) is required. Make sure to tap

on a part of the screen that has no button or active item. Note that Admin mode can be invoked

anywhere on any view of your App.

This special gesture will have a menu pop-up at the bottom of the screen with 2 options: Heatmaps

Mode and Visual Editor Mode. For this module, tap on Heatmaps Mode. Enter the one-time password

presented on the Dashboard into the dialog box and tap “Activate”. A red border around your App

screen will stay on as long as Heatmaps Mode is active. Heatmaps mode can be deactivated by

repeating a second time Azetone’s admin gesture (quintuple double-tap (iOS) or triple tap (Android)).

As soon as Heatmaps Mode is on, a secure App to Dashboard communication is active via Azetone’s

SDK. The SDK will first transmit a comprehensive list of all the views available in your App. No tagging or

action is required to launch this transmission. The App view list will show up on the left-hand side of the

screen. If the Dashboard does not display one or more screen shots yet, just navigate this or these views

of your App. After a few instants on the view, a screen shot will be automatically taken and uploaded

onto the Dashboard. After browsing through all the views of your App, you will see all the screen shots

populating the Dashboard and each gesture type being displayed over the App screens. Please allow for

a few hundred gestures to be collected before a clear picture of the interactions are becoming more

readily visible.

Each Heatmap for each App view can be filtered:

- by profile (using the profiles defined in the Profile Builder),

- by orientation (Portrait or Landscape)

- by date (predefined (last 7 or 30 days) or custom period)

- by device family (smartphone / tablet)

- and by gesture type

Tip: Gesture overlays are best represented when aggregated in at least hundreds, thousands or many more gestures. If the total number of gestures presented is too low, feel free to adjust your filters up to accommodate a more palatable number of gestures.

Optimize your App with A/B Testing

Once you have successfully installed Azetone’s SDK and considered creating profiles in our Profile

Builder (optional), you are ready for creating and rolling out your first A/B Tests! If you are unsure where

to start or what to test, it is usually a good idea to look at your Heatmaps to assess which parts of your

App are often used or under used or where your users might be struggling with your UI. When you are

ready to create your first A/B test, you have 2 ways to do so with Azetone:

- Using our Visual A/B testing mode: This is by far the easiest way to create a variant (also called

an experiment) for your App. It allows you to change virtually any property of any element in

your App UI by simply pointing and clicking within our Visual Editor. This is a great way to modify

on-the-fly any UI element of your App and does not require any pre-tagging of your App prior to

its submission to the store.

- Using our Universal A/B testing mode: This is the most advanced way of creating variants for

your App and it will allow you to go deeper that just changing UI elements. It can go as far as

activating or deactivating code blocks, modules or even entire App features. This mode requires

tagging or the element properties you may want to control via the Dashboard and this is usually

put in place by developers. Once the tags are set up, this mode can be operated by developers

or marketers alike.

Visual A/B Testing

After selecting Visual A/B testing on the left menu bar, you will have the ability to create a new A/B test

using our Visual Editor for iOS or for Android depending on which platform you want to work on. You

will also see a list of all the active or deployed tests as well as tests still in draft mode (not yet

completed) or in the process of being published.

Click on New Visual A/B Test (iOS or Android) to start creating a new A/B Test.

Initializing Visual Editor Mode Just like with our Heatmaps Admin mode, click on the Activate Visual Editor mode to create your App

variants. A dialog box will open displaying a one-time password. This password will be re-generated with

every Dashboard session. This password is meant to be entered on your device after activating the

Visual Editor mode with Azetone’s special Admin gesture.

On your device, Admin mode is activated but tapping 5 times with 2 fingers (quintuple double-tap) on

your App screen. Make sure to tap on a part of the screen that has no button or active item. Note that

Admin mode can be invoked anywhere on any view of your App.

This special gesture will have a menu pop-up at the bottom of the screen with 2 options: Heatmaps

Mode and Visual Editor Mode. For this module, tap on Visual Editor Mode. Enter the one-time password

presented on the Dashboard into the dialog box and tap “Activate”. A blue border around your App

screen will stay on as long as Visual Editor Mode is active. Visual Editor Mode can be deactivated by

repeating Azetone’s admin gesture (quintuple double-tap).

Tip: We have chosen to enable a highly secured communication system between your app and our Dashboard in Admin Mode to avoid any possible risk of fraudulent activity with your App. Communication in Admin Mode is happening via secured websocket using a special Port (8081 for iOS and 8082 for Android). In some cases, using our Visual Editor in an enterprise environment (behind a Firewall) may not work because your security policy has not enabled this Port. You may want to talk to your network administrator about opening this Port for you or use an open network to connect our Visual Editor to your device.

Creating variants of an A/B test As soon as Visual Editor Mode is activated in the App, the Dashboard will acknowledge the

communication with the App via Azetone’s SDK by indicating “Connected Device: 1” in the upper right

hand side of the Dashboard. Shortly after, the screen will be dimmed and the active page of the App will

be mapped out within the Dashboard. The first part which is collected is the tree of all the elements

present in the page or view of the App. It appears on the left of the screen and a full page preview of the

App is being rendered at the center of the screen.

Once complete, any element on the page can be selected either through the element tree or directly by

hovering the mouse over any element of the App UI. For each element, its applicable properties will be

displayed on the right of the screen as soon as it is selected. Make sure you click “Unselect” or click

again on the same element before trying to select another item.

To create a variant, simply change any of the properties of the selected element and click “OK”. If the

“OK” button is grayed, it means this change is not possible at this time, usually because an A/B test is

already running with this property. A variant can consist of as many updates as you wish on any

available property of any element on a given page. You will see the different updates you create listed

on the upper right hand side of the screen. If you wish to remove a specific update from your variant,

just click on the red “x” next to it in the “In progress Updates” list. Once a variant is complete, click on

Save. To create another variant, come back to the Visual Editor and the tree to select and change any

property.

Tip: With versions 4.1 and later of our SDKs, positions (X and Y coordinates) and sizes (Height and Width) can be edited directly from the Visual Editor. We recommend to test your size and position changes on different screen sizes before deploying a variation to a large number of devices. If your App is using Auto Layout, we have chosen NOT to override the automatic repositioning of objects on the page. In this case, we recommend letting a developer leverage our Universal A/B testing mode to adjust sizes and positions

You can create up to 8 different variants to test from. Once all of your variants are ready, you can review

them and click “Save and Assign Goals” to move to the next stage.

Defining conversion objectives The following Visual Editor page will allow you to select a conversion. By default, conversion is defined

as a click on any button on any page of your App. In order to reach the appropriate button just navigate

in your App to the appropriate page and select your preferred conversion action. Note that only

elements defined as “clickable” can be selected for a “click” (tap) conversion. When done, click on

“Save” and then “Save Goal(s) and Deploy”

You will then reach a new page allowing you to describe and program your A/B Test experiment.

Setting up the experiment parameters This page uncovers some of the unique functionalities of Azetone’s solution.

First on the Target Population, you have 2 levels of selection:

The first one is choosing the profile you want to focus your A/B test on. There are many benefits about

running your A/B test on a specific homogenous customer profile.

• First of all, designing a variant with a specific customer profile or persona will improve your

chances of making a real impact on conversions.

• Then, by running this A/B test on a given population, you will increase potential uplift in

conversions and shorten the amount of time it requires to identify which variant reliably

outperforms the others.

• And finally you may want to repeat the same or a similar test on your other customer profiles

and you will most certainly find out that each of your relevant customer profiles will lead to

(sometimes very) different variant performance results.

Second, the deployment of each variant can be managed based on your own user experience objectives.

A variant can either be displayed within your App only after collecting all its necessary elements or

properties and waiting for a next session to happen or it can show up as soon as possible, i.e. within the

course of a session as soon as the targeted page is displayed.

The use case for these controls is as follow:

- If your Mobile variant is “stealthy” enough, you may accept to alter user experience consistency

within one session in order to display your variant asap, as it will not be very disruptive to the

user. Similarly, if your users are not opening very frequently your App you may not be ready to

delay your variant appearance to the next session and select “as soon as possible”

- Conversely, if your variant is visually drastically different from the original and you don’t want to

disrupt your mobile user experience, you will prioritize session consistency and choose variant

appearance “only at next App activation”

Rolling out your experiment The final screen before publishing your experiment to users summarizes the key elements of your A/B

test: which users are you targeting, the estimated number of days it will require for your test to

complete and a preview of the variations allocated to the different users.

Clicking on Publish will package the experiment and send it to the server for processing. The experiment

will be posted as “being processed” for a short while. After a couple of minutes while the server

prepares the experiment and allocates the variants, the experiment is automatically moved to the Active

Tests section

Reporting For each A/B test, you have access to a full-fledged reporting providing you with at-a-glance information

about how your different variants are performing. No need to be an expert to understand the report.

The Variations (each with a zoomable miniature preview) will show the number of users, views and

conversions recorded by Azetone SDK. The conversion rates will be automatically calculate as well as the

chance for any variation to beat the original.

You may decide to commit a variation in production at any point in time but if these percentages are not

meaningful to you, just wait for the “Chance” field to turn green. This will mean you have a very high

statistical certainty that this variation is the best choice for a given population (95%+ threshold via a chi

square test for the statisticians among you!). Deploying a variation to all targeted users is as simple as a

click on the “Use variation” button --or “keep variation” in the case of the default view (a.k.a. variation A

or the default values you coded in your App) outperforming any of your attempted variants.

You will also find under this table comparative performance chart over time for each variant.

Universal A/B Testing

In certain ways, Universal A/B Testing is more rudimentary but at the same more powerful that Visual

A/B Testing. While visual A/B Testing makes it super easy to change any UI element and does not require

any prior preparation, Universal A/B Testing will require some preparation but allows to alter

significantly your App pages layout, ergonomics, functionalities, and activate or deactivate entire

portions of code in your App.

At least in the initial preparation phase where tagging will be required to be able to control any given

element from the Dashboard, a developer or at least a very technically proficient person is required to

perform the necessary tasks. Once the tags are done, a marketer can take over and use the Universal

A/B testing module but this module will always require solid understanding of what the implications for

the App of playing around with layouts, blocks of codes etc…

Create a new Experiment Creating a new Universal A/B Test is fairly similar to how you set the experiment parameters in the

Visual A/B Test mode. The main difference is that any tag that has been inserted in the App prior to its

latest build will appear automatically in the “Available tag” drop down list. This list is dynamic and will

evolve as you assign A/B test to any given tag. In order to avoid conflicts, any tag included in an active

test will automatically be excluded from the “Available tags” list.

On the Target Population section, you have 2 levels of selection: the first one is choosing the profile you

want to focus your A/B test on. There are many benefits about running your A/B test on a specific

homogenous customer profile.

• First of all, designing a variant with a specific customer profile or persona will improve your

chances of making a real impact on conversions.

• Then by running this A/B test on a given population, you will increase potential uplift in

conversions and shorten the amount of time it requires to identify which variant reliably

outperforms the others.

• And finally you may want to repeat the same or a similar test on your other customer profiles

and you will most certainly find out that each of your relevant customer profiles will lead to

(sometimes very) different variant performance results.

On the “Variations” section, you can create up to 8 variations for each element and select what type of

property you want to control. There are 4 main categories: Text (with a free text field), color (with a

color picker), image (with a PNG image uploader) and a custom field (to pass any predefined parameter

directly to the App). The latter will be used to pass for instance XY coordinates, sizes, integers or triggers

to activate or deactivate code blocks etc…

Universal A/B Test Reporting Once the experiment is published, the results of the A/B test can be checked by clicking on the action

button of the appropriate Active Test. The report will include the number of users, views and

conversions recorded by Azetone SDK. The conversion rates will be automatically calculate as well as the

chance for any variation to beat the original.

You may decide to commit a variation in production at any point in time but if these percentages are not

meaningful to you, just wait for the “Chance” field to turn green. This will mean you have a very high

statistical certainty that this variation is the best choice for a given population (95% threshold for the

statisticians among you!). Deploying a variation to all targeted users is as simple as a click on the “Use

variation” button --or “keep variation” in the case of the default view (a.k.a. variation A or the default

values you coded in your App) outperforming any of your attempted variants.

Creating a Group Test (Multi Variate Test) By default, the A/B test in Universal A/B Testing are handling 1 single property at a time. However, it is

possible to group as many as 4 different properties with up to 8 different variations each and create a

multi-variate test where a wider but coordinated variation of your App is built and deployed.

The variation groups are created by simple drag and drop and assembling the different properties

together as you see them fit together.

The Group Experiment can then be deployed in a similar fashion to other Visual or Universal A/B Tests

leveraging Azetone’s Profile Builder.

Likewise, reporting, controls and deployment options are similar to those found in traditional Universal

A/B Test reporting.

With Personalization, maximize your App relevance and efficiency for

your users

After running similar A/B tests on different user segments, you will quickly realize that all your

customers are not reacting in the same way to your variants. You will even realize that some variants

work well with some segment with other variants work much better with other. By acting on this, you

will make your first steps towards a truly personalized user experience.

With App Personalization, we are leveraging similar building blocks to A/B testing but with quite a

different approach and objectives.

First the idea of app personalization needs to be judged at the app level as much as at the object or page

level. This means beyond consumption or conversion on a specific item, app personalization KPI need to

be defined at the App level and this is where UX Analytics can help track whether personalization is

delivering actual impact and performance on user retention, attrition, engagement, satisfaction and

more…

At the high level, just like for Universal A/B testing we have 2 Personalization modules: Universal and

Universal Grouped

Universal Personalization With Universal Personalization, you will leverage a tag placed in the code (most often a custom tag to

activate a code block or feature) and assign different values to this experiment

One of the main differences with A/B testing is that you will have the ability to pre-define an activation

period for this personalization (this can be either valid for a few days or be defined as recurring)

The other main difference is that you will assign a profile (from your existing Profile Builder segments)

directly to each variation. You can deploy for one tag up to 20 different variants to 20 different profiles.

The deployment and tracking is similar to A/B testing and reports will offer an analysis of each view of

personalization and -when applicable- an associated conversion!

Grouped Personalization Grouped Personalization allows for more complex and flexible personalization scenario. It will allow you

for instance to customize on-the-fly a complete tile on your app with modifying in a synchronized

fashion the text, the color, the image and functionality behind a tile (or button) in one go. This can be

used also to customize a complete multi-step acquisition or conversion funnel based on user profile.

You can deploy for one tag up to 30 different variant combinations to 30 different profiles!

Q&A

How does Azetone impact my App performance? Performance and stability of our SDK have always been our top priorities because we feel that no matter

what, you should not accept any trade-off in user experience when using our Mobile UX Analytics, A/B

Testing or Personalization. We have done all kinds of benchmarks and optimization and are very

confident to claim that our SDK will have absolutely zero perceivable impact on your users. Ask us for

specific competitive benchmarks and customer testimonials!

How does Azetone affect device memory, network and battery usage? We have taken a page from the best-in-class SDKs on the market to reach the SDK with the lowest

memory footprint in its category! As far as network and battery is concerned, our SDK is communicating

with our servers with super-optimized exchanges (just a few KBs max) and you have the ability to

throttle the frequency of exchanges between the Apps and our servers from a call every 15 mins to a call

every 15 hours. And these communications do not require the App to be active in the foreground to

happen!

How do your servers perform when facing peak usage? Our servers are setup with redundancy in mind and with a 3-tier architecture which allows to absorb any

kind of heavy load. Moreover, we are hosted on Azure which allows us to deploy our servers at the

country and region level, at the closest to our end users for best response time.

What happens when Azetone servers experience an outage? In the very highly unlikely event of our 3-tiered redundant server architecture becoming unavailable,

your existing A/B testing, personalization and UX analytics campaigns would continue to run unaffected.

Because our overall architecture allow our SDK to operate in completely autonomous mode (should an

end user be temporarily out of network), our servers can be unreachable for a period of time and our

SDK will keep serving variations and collect usage data as usual. At next available connection time with

our server, the usage history will simply be reconstructed as if nothing happened.

How secure are the transmissions between Azetone and the Apps? We take security and privacy with utmost concern. The communications between our SDKs and our

servers are SSL encrypted with a unique key per App. We also enable a secured websocket

communication channel when activating our Visual Editor. In addition these Visual Editing session are

secured via a unique session-id password that ensures only a certified administrator can create an App

variation.

How do you guarantee Apps users privacy? By default, there are no customer-specific identifiable information stored on our servers. We create our

own proprietary unique ID for every device connected to our servers and will only keep information that

you will decide to enter in our systems.

For instance you may want to use our event tracker to collect some info from your app to create user

profiles. This could be customer identifiable info but you may choose to do a one-way encryption of this

data and match it with similarly encrypted data coming some your own CRM or DMP systems. This

allows you to create customer segments with absolutely no identifiable user data stored on our

systems!