How to calculate retention and churn uplift in Mobile Apps

There is a good posts around the web on user retention for websites but Mobile App developers initially focussed for a (long, long) time on “Downloads” as a measure of credibility. Now the App industry is maturing rapidly to understand that every App is a leaky bucket – that you lose users over time and you need to proactively plug the gaps by engaging your users and adding value to their day.

Meet the Churn Curve

In general a graphical representation of users leaving your app looks like this:

Activity profile of a churning user

Its a good chart for communicating the concept but its over-simplified – why?

  1. That chart was like you took a snapshot of only the users on September 1st and then how long (in days or weeks or months) they continued to open your App.
  2. You are actually acquiring downloads and users (hopefully) everyday
  3. Depending on your marketing activities and word-of-mouth – different users will have different retention characteristics
  4. The utility of your App. A game might have an average lifecycle in days – a public transport App is retained as long as the user commutes!
  5. lots of other variables like holidays, seasons, relevance of your App to time of year (e.g a Football League App’s cycle is very different to a Black Friday Shopping App’s)

Getting more specific with Cohort Chart

So continuous acquisition of users means that a cohort chart is more relevant.

Percentage Retention Cohort

Percentage Retention Cohort

So the cool thing about this is you can see the churn rate and/or retention rate for users that downloaded, 12 weeks ago, 11 weeks ago, 3 weeks ago etc etc.

Just for clarity:

(R)etention = 1 – (C)hurn
if you have 5% churn rate per week, then your monthly retention would be roughly:
100% – (5% * 52 weeks)/12 months = 78.33%

This is a more concise way of describing the success rate of your “Engagement Strategy” than purely talking about MAUs (Monthly Active Users). Don’t get me wrong MAUs is a much better metric than the vanity metric of “Downloads”. People love to talk about “We’ve got over 300,000 downloads” but don’t know or won’t say what the MAUs are. It reminds me of the joke….

“A million people walk into a Silicon Valley bar. Nobody buys anything.
The bar is declared a huge success.”

Graphing Cohorts

The Cohort Chart can be represented by the following graph:

12 Week Retention Cohort

12 Week Retention Cohort

Averaging Cohorts

Its an interesting chart but not very actionable – here is an average across the datapoints.

12 Week Average Retention

12 Week Average Retention

You can see we are back with a simple understandable curve similar to our original chart which shows you can either express it as a “snapshot” or an average across the dynamic user-base. As you can see its easily shows that around Week 6 we would want to understand why users are leaving the App. We would revisit our engagement strategy to “flatten the churn curve”.

Getting a baseline of Retention or Churn

You might have missed before how I glibly provided an example of “5% churn rate”. You can see from this chart that churn varies from week-to-week and for cohort-to-cohort. So its not easy to just say “5%”.

Today, we think the best way to define (R)etention or (C)hurn is to run a “line of best fit” through the points you are interested in. This means you could:

  • pick one cohort (e.g Week 12)
  • pick 4 consecutive weeks of cohorts
  • pick the average chart above.


NOTE: this example is best for Apps that aim to retain users for long periods of time. Its equally valid to measure retention in terms of days instead of weeks.


Line of Best Fit (Linear Least Squares)

The simplest and most common method of getting the line of best fit is not actually with a ruler – but using a calculation called “Linear Least Squares“. You can get complex with this stuff (non-linear etc) but for the average developer, product manager, marketer of an App, they just need to get their baseline and start figuring out how to improve it (get uplift!). Picking the average chart above (12 weeks of cohort data) we get a new chart.

12 Week Line of Best Fit

12 Week Line of Best Fit

Whats most important to App developers, product managers or marketers is the slope/gradient of the line. Your mission….should you choose to accept it….is to reduce the gradient of the line. A gradient of -3.5 is much better than a slope of -5!

Weekly Churn and Retention

Because each cohort starts with 100% installs, the slope is actually the weekly churn rate so a slope of 5% then C=5%. As discussed before then R(monthly)=78.33%.

Calculate Retention Uplift (RU)

Phew!!! thats a lot of foundation work to get to a very simple uplift calculation – as I said before:

“Your mission….should you choose to accept it….is to reduce the gradient of the line”

You can take any two equal samples of your C or R to get the uplift:

Retention Uplift (RU) =

(Clater- CInitial)*100

if you have a initial C = -5 and later C= -3.5, then:
Retention Uplift (RU) =

(-5 – (-3.5))*100

Retention Uplift (RU) = 42.8

Obviously increasing RU towards 100 is better!

Choosing the right period

I’m a big believer in looking at short and mid-term periods. In the example above the 12-week data is very useful because we see the big picture. We discover the drop-off around week 6.
Further, in this example if we only look at the first week we don’t learn much because retention is generally 100%. (you don’t yet know if your users have left you).
However, its important to not wait for 12 weeks of data to make decisions. I think you should be looking at 4 week periods as well to get a sharper period.
For calculating uplift you can choose any two periods (even overlapping) but obviously your “later” period, should be including this week – you want to know how you are tracking now!!!

Measuring “Active Users” or Uninstalls

The big difference for Apps is that you might only want to engage users a few times a month. I’ve talked before about how stupid it is to try to keep people engaged by spamming them – you are not Facebook so don’t be pushy about your relationship with users.
For this reason, there is two ways to measure user engagement:

  1. Have they opened the App in that week?
  2. Do they still have your App installed?

StreetHawk allows both to be tracked and in fact (surprise!) the chart above is actually tracking Uninstalls – a very powerful metric for just how MUCH users don’t love your App anymore :)
You can always expect “Active User” Churn to be more brutal than Uninstall Churn.

StreetHawk makes this easy

I hope the post has been useful – whilst the content might be a little detailed, you don’t really need to think about it. The StreetHawk platform does all the leg work in helping you understand and optimize to “flatten out the churn curve”

Whitepaper: Leveraging CRM data for right-time engagement

We often get questions from enterprise companies with Apps about how we make it easy to integrate with more specific customer information.

At StreetHawk we kind of take the technical details of this for granted because we do it everyday….its just second nature. We didn’t realise that many larger organisations have to:

  • educate their management
  • educate their IT teams
  • “be educated” themselves
  • present to the CMO

about how to intersect real-time mobile usage with existing data that may be locked up in a:

  • enterprise CRM
  • loyalty system
  • marketing system
  • or some other backend.

The goal is usually to provide a RELEVANT push notification or InApp interaction (deliver the user some personalised content, news or offer) based on the current context. In many organisations (especially enterprises) the CRM data is the “single source of truth” – but how to unlock it???

So we originally wrote a quick blog post to quickly explain the technical details but is now expanded to cover how CRM data is evolving to be used with real-time mobile platforms like StreetHawk. So if you’d like to get more detail and have a tool for presenting to your management or IT department please click on the image below!

How to send your first push notification


StreetHawk supports a myriad of rich Push (Apple APN and Google GCM) and InApp notifications, triggers and content, e.g:

  • Open your registration screen or your offers screen
  • Show then a video inside the App or Launch Youtube externally
  • Send them to the AppStore to Rate or Upgrade your App
  • Plus much more….

This is a “back-to-basics” post for people trying StreetHawk for the first time and I’ll walk you through the 3 Push Types you can use:

  1. Manual Push from the console
  2. Use our Push API to target a user (or users)
  3. Use our Campaign API for triggered Pushes

I’ll be using our SHSample (for Android) demo app to explain – you can download the code from here. You can do the same with SHSample for iOS but you need to register the App on your Apple Developer Account and generate Push Certificates so its a bit more complex – if you’ve not done this already, see our documentation for that.


METHOD 1. Manual Push from the console

If you’ve integrated StreetHawk into your App, then the console will show the installation running on your phone/tablet (NOTE: don’t use a simulator).

Step1: If you’ve just installed and opened the App, go to your Campaigns-> All Segments. Click on the bubble “Newbies”. You will get a dialog list of “Installs” for your App.

Step 2: Browse through and look for your specific phone/tablet and the latest version of the App (perhaps you’ve built/run/removed a few times before).

Step 3: Click “Send Notification”. Fill out the title and message and click “Send

BINGO! – you have your first push notification on your phone.


METHOD 2. Use our Push API to target a user

If you return to the list in Step 3 above, click on the row of your device – you will see an “installid”, this is the StreetHawk reference to a specific App on a specific Device (Phone or Tablet). To use the StreetHawk API you can use:

  • This “installid” or
  • Your own user ID which we call “sh_cuid”. For a detailed discussion of how you tag a user with “sh_cuid” please refer to this blog post and this documentation.

I’m going to use the cookie authentication approach for simplicity. Here are code snippets in bash/curl and python.

   -d "username=<YOUR_EMAIL_FOR_CONSOLE_USER>& 
   -c ~/cookies

Where <YOUR_EMAIL_FOR_CONSOLE_USER> is the user you logged in with in Method 1.
This user needs to have "OWNER" or "DEVELOPER" level privileges.
import requests
import simplejson as json

APP_KEY = 'SHSample'

HOST = ''

#login and get the session cookie
params = dict(username=USERNAME, password=PASSWORD)
r = + '/v1/users/login', params)
assert r.status_code == 200, r
COOKIES = r.cookies

You will get a JSON response confirming success or fail. The bash example uses a ~/cookies file. (This is an Apple but on Windows it could be c:cookies.

Now you authenticated, you can send a push notification using our “publish” API. The first method is to the StreetHawk installed which is a GUID that looks like “807AOS2ES48M6NWR”

curl -X POST "  
   -b ~/cookies
params = dict(installid=, code=8004, title="Hello Hawk",
        msg="this is the message",
r = + '/v1/installs/publish', params, cookies=COOKIES)

where the terms “c”, “t”, “m”, “alert” are documented here. (In this case I am sending a “c=8004″ which is a simple “Open the App” command. The “d=abcd” instructs the StreetHawk SDK to open a screen called abcd – if that does not exist, then just open the default or home page.)

BINGO! – you have your first PROGRAMATIC push notification on your phone. This is nice but you can also use your own user ID (the “sh_cuid”).

As discussed in this blog post, tagging is a really cool way to create “primary key” between your backend and the StreetHawk system. You usually tag the sh_cuid from the phone – I’ll use the SHSample App to create this.

SHSample Menu - we can create a tag

SHSample Menu – we can create a tag

In iOS this would be done like:

NSString *string_value = @"";
[StreetHawk tagString:string_value forKey:@"sh_cuid"];

In Android this would be done like:

String string_value = "";
StreetHawk.INSTANCE.tagString("sh_cuid", string_value );
SHSample setting a tag

SHSample setting a tag

Now if I refresh my Install details dialog I can see the sh_cuid.


sh_cuid_details updated after tagging

Now to send a programmatic push to your own user ID!

curl -X GET " 
   -b ~/cookies
params = dict(app_key=APP_KEY, sh_cuid="", code=8004, title="Hello Hawk",
        msg="this is the message",
r = + '/v1/installs/publish', params, cookies=COOKIES)

BINGO! – you have your first PROGRAMATIC push using your own user ID (the “sh_cuid”).

cuid push notification on android

cuid push notification on android

Getting Push History

A powerful API is available to access the history of communication to each user or install.

   -b ~/cookies
params = dict(installid=<installid>)
r = requests.get(HOST + '/v1/installs/push_history', params=params, cookies=COOKIES)

Sometimes a user will have lots of push history, so you can “page” through the data by using count & offset values defined here.

METHOD 3. Use our Campaign API for triggered Pushes

The final method is the most powerful approach and it gives you the capability to target groups of users (or segments of users) for a defined period. This is called a “Campaign” and you have two options to run campaigns:

  • Once – The campaign will run once and only once for the current installed users/devices that match the campaign criteria
  • Permanent – The campaign will run for the period between “activates_at” and “expires_at” as long as status=1 (enabled)

So here is a quick campaign to target all recent android users with sh_cuid containing “david”. This takes just a few seconds to create in the StreetHawk Campaign Console. When you drag and drop these filters you can see how many users potentially match – so I’ve chosen some filters just to select me for this blog post.

"Recent Android Users Called David" Campaign

“Recent Android Users Called David” Campaign

If I click “View Users” I can quickly see that I have just one matching user and could manually push to them as per Method 1. But now I will show how that can be done programmatically.

The API call to create a campaign is documented here – and the call might look something like this.

curl -X POST 
    -b ~/cookies 
    -d "app_key=SHSample" 
    -d "priority=1000" 
    -d "status=0" 
    -d "title=Recent Android Users Called David" 
    -d "rules=[{ "filter": "anniversary", "key": "sh_app_launch", "operator": "lt", "value": 4, "unit": "days" }, 
         { "filter": "platform", "key": "sh_platform", "value": "android" }, 
         { "filter": "custom", "key": "sh_cuid", "type": "string", "operator": "contains", "value": "david" }, 
         {"action":"app_page", "type":"push","title":"Hello Hawk 3", "msg":"This is the third message", "data":{}}]"
params = dict(app_key=APP_KEY, 
        title="Recent Android Users Called David",
        rules=json.dumps([{ "filter": "anniversary", "key": "sh_app_launch", "operator": "lt", "value": 3, "unit": "days" },
 { "filter": "platform", "key": "sh_platform", "value": "android" }, 
 { "filter": "custom", "key": "sh_cuid", "type": "string", "operator": "contains", "value": "david" },
 {"action":"app_page", "type":"push","title":"Hello Hawk 3", "msg":"This is the third message"}])
r = + '/v1/campaigns/create', params, cookies=COOKIES)



So there you have 3 (or 4 if you include via installed or sh_cuid) methods for sending a basic push to users. All pushes are traceable regardless of method and you have the option to do this either graphically or programmatically.

In summary, StreetHawk provide the most comprehensive delivery of both transactional and campaign generated push – incredible power and incredible flexibility.

If you have any questions, hit me up in the comments or on twitter at @streethawkapp.


Use your enterprise data to personalise App user engagement

Simple and Secure Integrations

Some sectors (such as banking) are extremely sensitive to customer data outside their own firewall or cloud. We totally get this – previously founding ThreatMetrix to fraud detection for customers makes me pretty aware of what our customers want to share. With StreetHawk we want App developers to be able to automate engagement easily and quickly without having to overthink the data integration component, so this post explains:

  1. the simplest integration
  2. additional security integration

This diagram shows how you can liberate data in backend systems to make it relevant for Mobile Engagement Automation. Its slightly geeky so if you are a marketer or product manager you might like to forward to your favourite developer.

Make Enterprise backend data actionable

Make Enterprise backend data actionable

Let me explain…. :)

Step 1: As you know StreetHawk plugs into iOS and Android in about 15 minutes. This gets you started with segmentation, reporting and campaigns for App user engagement. So this is “YOUR APP” with the StreetHawk SDK integrated.

Step 2: App users can be “tagged” from the App side. This can be when the user clicks a button or registers etc. This is client-side tagging and a very simple and quick way to segment users based on their interaction with the application. The SDK API describes this here (for iOS). The most important “tag” you can tell StreetHawk is “sh_cuid” – this is your user’s ID (from your system). The reason why this is important is that it helps you in Step 3!

Step 3: App users can be “tagged” from your Backend or Enterprise system. So it doesn’t matter whether you have a Ruby on Rails custom App or a SalesForce CRM or a Customer Loyalty System – you can now start to liberate that data to make more segmented, personalised interaction with your mobile users. The tagging API you call from the backend is here.

Using the “sh_cuid” defined in Step 2 that is the “primary key” that you can tag users from the backend. In this example we can see that “VIP” and “gender”**.

More security

In the diagram it says “sh_cuid” is a primary key – (anonymized if you wish):

  • often a sh_cuid might be a magic number (or GUID) from your backend system
  • for some Apps it is the email address of the user
  • it might be a public id (for the sake of this example, lets say its a bank account ID)

Some App developers might be sensitive to sharing the customer’s email address or a “bank account ID) – so this is an example about how iOS Apps could use the Objective C

"#import <CommonCrypto/CommonDigest.h>"

to generate an anonymised email address. For a few extra lines you get this capability. See the Stackoverflow helper code here.

NSString *sha1Email = [utility sha1:<your_app_user_email_ID>];
[StreetHawk tagString:sha1Email forKey:@"sh_cuid"];


Cool! – So What’s the catch?

What you win on the swings you lose on the roundabout – StreetHawk supports (on some plans) ability to send triggered email, so you’ll need to share the correct email address with us (using the “sh_email” tag) if you want us to do that. So sometimes more security results in reduced functionality – but its your call!

At StreetHawk we don’t really mind what you do, the platform has a huge set of features that you might want to use. In the case of triggered emails – you can reach these people if they have push notifications disabled by sending them an email – otherwise they are “unreachable”.

Summary and Suggestion

With StreetHawk, the more you tag (from within the App or from your backend) the more capability  you have for mobile engagement automation or mobile marketing automation – so its a balance of what you want to share and what value you deliver to the user.

So consider the example above where “VIP”: true. If this was a loyalty application and the user has a particular points balance – you may not wish to tag those points in StreetHawk, so you can tag just a flag “VIP”. This is simple and allows you to segment VIP users from normal users. A more sophisticated example might be Bronze, Silver, Gold, Platinum for different bands of loyalty points. Its your call! Drop me a note if you want more explanation.

Curl & Python examples to tag a user from your backend

curl -X POST -d "app_key= APP_KEY" 
   -d "sh_cuid=<your user's id>" 
   -d "key=myNewKey" 
   -d "string=myNewStringValue" 
   -b ~/cookies 
params = dict(app_key=APP_KEY, 
   sh_cuid=<your user's id>,
r =', params, cookies=COOKIES)


** actually we have a reserved tag “sh_gender” which is more powerful.

How to Maximise user upgrades of your App

If you are constantly iterating your App, you want all your user’s to keep up (if it will improve their experience). Its tough getting upgrades of your App to your latest version because so many Apps are doing it all the time.  Heres a few tips to consider.

1. What does my current installed user base look like?If you have a distribution like this you have a bunch of users on different versions – that means you really have a job ahead of you to get everyone to the latest. This is bad for business because:

  • Many of your users are getting sub-standard experience – thats bad for growth via recommendations (k-factor – see more here)
  • You can’t evolve your backend changes because you are wasting time on backward compatibility

Pie Chart of users by App version

Pie Chart of users by App version

2. For each version that is significantly different (either in function or user perception) – Segment your users with different benefits being highlighted.If some users have been having crashes, you could target them differently. Here is how you could target iOS users who are on an old version but are still using the App.

An example Segmentation Filter

An example Segmentation Filter

3. Time your prompt and Make it compelling!This is a great prompt, its attractive and somewhat compelling. I think it could explain to me benefits a little more but that is something you can run A/B Splits on. As I mentioned in #2 segmentation means you can target the “right-message” to the “right-segment”.Timing is interesting:

  • This example did it when I opened the App. In fact it did it every time I re-opened it – without any specific benefit explained.
  • Via a Push Campaign – with StreetHawk you can deliver this around the time the user typically uses your App
  • When the user is in the App but DEFERRED until they get to a specific screen. I really like this kind of timing because sometimes you just want some quick info without stuffing around with an upgrade. Why put your users through pain if they don’t know (or value) the gain!!!????

An Attractive Upgrade Prompt.

An Attractive Upgrade Prompt.

4. Measure the effectiveness of each campaign.If you’ve run multiple campaigns then you may find that one method is statistically more successful than others – you can double-down on that.

General Upgrade Prompt

General Upgrade Prompt

 5. Rinse and Repeat!Obviously some users won’t come back but from #4 you can know who responded and get an update from the report in #1 to get a new snapshot of the user base.


So thats a mobile engagement automation approach to boosting your user base to the latest App version. Let us know in the comments or on Twitter if you’ve got other ideas that have been super successful in upgrade conversions.



Mobile Engagement Automation in PhoneGap (Cordova)

One popular post on our blog is about our PhoneGap and Cordova integrations – PhoneGap is a great way to get an App into market for iOS and Android:

  • quickly using HTML5 and Javascript for the App content and logic
  • and add StreetHawk for Marketing Automation or Engagement Automation.
  • Thats an extremely potent accelerant for getting Apps released and retaining users!

However, I’d forgotten that we’d vastly improved the integration to become a plugin and that is now available. If you have PhoneGap App, its literally a few minutes to add StreetHawk to it and immediately have a powerful way of doing mobile engagement automation!

So I stand corrected – here are the instructions to get you started – and this is the TL;DR:

$ cordova plugin add –variable APP_KEY=<YOUR_APPLICATIONS_APP_KEY>
$ cordova run android
$ cordova run iOS


And here is an Open Source sample App you can use to test it quickly.

This gives you access to:

  • geofences and background location
  • push and InApp notifications (both simple and all our rich options)
  • user segmentation
  • …and all the other great StreetHawk Mobile
  • we can also arrange iBeacon access for you if you contact us.

The StreetHawk plugins support 3.x. We also support 2.x but contact us as its the old integration style – a few more steps.

StreetHawk supports Android Wear (LG G Watch example)

Getting into Wearables

Its no suprise that StreetHawk is staffed with Geeks and so its common to “wander off the path” and get interested in stuff thats just not relevent. We’ll call that therapy :)

On the surface Google’s announcement of the “Android Wear” SDK might seem pretty irrelevent to mainstream business but us geeks can justify buying a Watch is completely in-line with StreetHawk’s Engagement Automation mission!

Here is a few practical bullets about StreetHawk powered Apps work with Android Wear devices.

Continue reading

Why iBeacons are just a data point not a solution

I’ve posted two videos I did for a presentation about user lifecycle and user journey.

From my previous posts about iBeacon hype its clear that a lot of people are inspired and confused by the potential of iBeacons and I wanted a simple way to put it in context.


The simple truth is that in a retail/brand context the App that detects an iBeacon is responsible for the filtering of the “Call-to-Action”.

In the worst-case scenario, this will be Apps yelling at us everyfew metres we walk through a retail precinct. In my iBeacon privacy and segmentation slides I suggested that Tom Cruise being yelled at by billboards is not as dystopic as the impersonal spam we will see from overzealous marketers.

So the context of the two videos is:
1. Alex is a consumer who uses a recipe or shopping list App. She tags a favourite recipe in the kitchen at home – her personal preference and something that the App or Mobile Engagement Automation can user as a degree of personalisation.
2. She is an active user of the recipe’s App and therefore the interaction is welcome and not a surprise.
3. A target geofence campaign triggers when she is picking up the kids from school (the supermarket is a few 100m from school pickups)
4. The call-to-action is relevant and compelling enough to trigger Alex’s visit to the supermarket.
5. Only at this late stage of the user journey does the first iBeacon actually play a role in the user-engagement. In fact this iBeacon does not annoy the user, it just records that a foot-fall event occurred as part of the entire campaign. (you MUST measure effectiveness of campaigns).
6. Checkout or Aisle based beacons may pick up follow-on PERSONALIZED user interaction.

So the left video is the example rules being dragged and dropped. The right video is the user’s journey.

So its not hard with the right tools like StreetHawk to deliver personalised experiences in real-time but its important the marketer or product manager is not lazy and thinking from their own perspective. Personalized location-based marketing really should be a deep intersect between:

  • App engagement
  • CRM history and demographics
  • context (location/activity)

I’ve got a post that drills into this intersect a bit more.

Lets hope the lazy marketers don’t pollute the user experience!

6 New StreetHawk Features

Making User Engagement Easier

Over the last month our awesome backend and front-end teams have quietly added a bunch of new features that help both Developers and Marketers. Our mission is to make user engagement easier for you and that means:

  • meaningful user segmentation
  • visual identification of where churn is happening
  • be able engage users UNIQUELY at each stage of the lifecycle
  • be able to message users simply & quickly (drag-and-drop rather than logging a ticket for your developers to write some code)
  • measure the performance of any communication (messages and/or campaigns)

We’ve had most of these capabilities in place and the addition of segmentation bubbles has been terrific for providing insights into the key user segments. This month the new features literally “drilled-in” to existing features to deliver more power for you.

Drill into users in a campaign or segment


We’ve previously allowed you to see the performance of Matches, Notifications, Views for every campaign in real-time. This is great to see how a campaign is going but didn’t tell you who those users were or any deeper data. We’ve now delivered real-time deeper insights.

1(a) View Users

In a Campaigns you will now see a “View Users” button. In the Segments report – you can now click on a bubble (segment of users) - When you click:


  • You can see a list (pages) of users (when they installed, last usage, session counts, City/Country etc). This really humanises your user base and just gives you additional flavour of where unregistered users might be coming from. If you refer back to my previous post on why forcing registration is bad this helps you get more comfortable about segments of anonymous users but still having insight into how they user your App.
  • You can send a message directly to a selected user. This makes 1-to-1 messages really simple, we don’t expect it to be used a lot but is super helpful for developers just testing their integrations quickly & simply.


1(b) User Details

When you click on a row you then “drill-in” to a specific user:UserDetails
  • See User Details – All the data about a phone type, operating system, App Version and User Tags (both StreetHawk and your Custom Tags) are browsable. Whether your developers are tagging users from the App or from your backend/CRM/Loyalty system – you can see the details for that user.
  • See Campaign History – as you run multiple Campaigns to target users at different stages of the User Lifecycle, this view shows what Campaigns a user has matched.
  • See received Notifications – similar to Campaign History for either campaigns or via direct push API
  • See User Feedback(s)
We still need to implement some UI niceties and we could also implement multi-select of users for push if you we get enough interest. On the UI front we’ll be overhauling the experience over the next few months.


2. Push Throttling (Push Interval)

StreetHawk has always advocated “right-time” push and had protections for not over-messaging your users. We’ve now made this simpler on an App level for you to define the absolute limit (in seconds) between when a push should be sent (in campaigns). Find it under your App settings/Push section (where you loaded your IOS Push Certificates)


3. “Best Time” Push

Per your requests: this is an awesome new feature. It allows triggered push to occur to users at the times StreetHawk is best for that UNIQUE user – so you don’t need to second-guess these things.
To find it, go to yourCampaign settings (Step 3)/Advanced, you will see “Let StreetHawk choose the best time to send a push.” If you are doing programmatic campaigns refer to the docs here.
How it works: “Best Time” is based on times that this user has traditionally used your App – for example if they open your App mostly on the Train to/from work then thats the time StreetHawk will target. If they use your App during lunchtime, then push will happen then.
At the moment we round to specific behaviours:
- does not differentiate days (so still think about setting days of week if you
- works on hourly boundaries (if a user opens the App at 5:12pm they’ll get the push closer to 5:00pm)
- if a user has only used the App once, then the trigger will be on the same time (on subsequent days) when they first installed. This is because we don’t have much history – a campaign won’t fire with “Best Time” on the same day as they installed – we wait a day….makes sense right? :)


3. Deferred Push Permission

This one is for the developers our there – but its super exciting. The latest update of the IOS SDK implements deferred push prompt and takes its inspiration from this article
The logic is simple and powerful – you need to earn your users’ trust before prompting them.

iOS Push Permission Prompt

iOS Push Permission Prompt

However, deferring push has some downsides. For push campaigns it would make sense to drag in a ‘Permissions” Filter with “Push Allowed” to make sure push campaigns only target those that can receive – you should be doing this anyway but its more important now that users may opt-in to the push later in the User Lifecycle. If the user opted to accept push after they previously matched the campaign, then they won’t match again.


4. Deferred Location Permission

Same as Push Permissions, if you plan to use location specifics you can ask the user at the “right-time”. Developers can read about both permissions here.


5. User Feedback

Prompt your users for feedback without writing a single line of code. For example:
  • ask a user how hard/easy a level was in the game
  • ask a user how their shopping experience was
  • run A/B split tests to find the best conversions
  • trigger the questions at different times of day or point in the User Lifecycle
Android Feedback Prompt
iOS Feedback Prompt

6. Available but hidden (let us know if you want to use)

We’ve added some great communication features that extend your reach and engagement – we are not making these generally available as the usage and billing requirements are per-case. Also, you may already have a preferred provider that we can trigger to (via an API call). For example if you want StreetHawk to trigger an email then you may already have accounts with SendGrid, Mailgun, MailChimp/Bonobo etc – so just talk to us. Here they are:

  • Send SMS to user as a Campaign Action.
  • Send Email to user as a Campaign Action.
  • Both also need appropriate tagging of the users contact details (sh_email, sh_phone tags need to be set). Your developers can do this from from the App or from your backend/CRM/Loyalty system.
  • Ability to call an external API as a Campaign Action.


So thats a pretty rich set of features – let us know what you think or how we can make the documentation and user interface easier for you to use. The chances are if you need some clarification, then someone else will need that too!



Echelon 2014 Report

Warning: this is one of those “airline lounge” essays – a brain dump. I’ll get back to normal blogging later today with continuation of the  “How to understand who your users are” series.

I just spent a few days at Echelon 2014 conference in Singapore. Echelon is a conference specifically bringing together innovative tech companies with investors all based in the Asian region. Many companies are startups that are on their way and others are not much more than a deck of slides.

My TL;DR insights from the trip:


  1. Any advantage Australia originally had in building startup ecosystems is evaporating. We are falling behind Asia’s innovators and ecosystem.
  2. Government involvement in innovation takes 2 forms:
    • active support (Grants, education/mentorship programs)
    • get out of the way (legislate so market forces can flourish. Capital Gains Tax breaks, Stock Options, Tax Rebates)
  3. The support from 2.1 is useful in nascent markets but also creates “Grantreprenuer” & Entitlement mindsets.
  4. Malcolm Turnbull is the problem for Australia because he positions himself as an open and understanding advocate of innovation but has neither argued for an innovation mandate nor implemented any of the well know changes required.
  5. Investors invest in companies domiciled in “friendly” countries.
  6. Its STILL mobile-first in Asia!


More on Echelon…..

E27 runs the event (check #echelon2014 for comments) and it seems agenda is to foster communities across the region and educate via events. Big shoutout to Mohan (@mohanbelani) and his team for an incredibly successful event.

There were comments from locals that many Echelon speakers were ‘the usual suspects’ – I’ve seen this in the Australian startup scene but generally there is now more depth in the Sydney community to get speakers with actual experience. That said: I don’t think it matters as the audience was from out-of-town and also there was some high quality speakers flown in. It was interesting that McClure was fairly taciturn and measured – I certainly noticed that the audience is fairly reserved so maybe last year he scared the locals :)


I’ve previously founded two successful global startups and so being on my 3rd is quite often a matter-of-fact affair – I love tracking to product-market-fit and the roller coaster that everything “startup” entails. But what I really love is working with a small team who are bloody fantastic; all pulling together to create a world-beating product. No politics or CYA, just everyone rowing in the same direction. Its easy to get out of bed to work with this team!

But as I said, the sheer mountain of work and relentless uncertainty sometimes means I don’t get screamingly super-pumped and do the monkey like Steve Ballmer (link). So attending Echelon was energising to mix with a lot of high energy people (youngsters and seasoned) and the huge sense of optimism that someone will break out and become a huge success.

Exits in Asiapac are still a rarity but Vixxi and Viber acquired by Rakutan show signs that there are big rewards for toil and great execution. There is a gold/oil rush mentality but something about the people in tech means the rush has commerarderie and never openly descends into kill or be killed like “There will be blood” – of course once your competition is known, its hand-to-hand combat on so many fronts that battles are won incrementally by sheer hustle.


The reality is that most battles are with your own delusions. 80% of businesses at Echelon this year will not be around next year – some won’t be around next month – the attrition is largely due to shipping a product that no-one cares enough to pay for.

In the US angel and many VC-backed companies huge user traction so monetisation is deferred and the funding provides enough runway to “figure it out”. In Australia the dearth of investors who understand tech is small and so mostly companies get funded after repeatable revenue is found – thats not a bad thing but it guarantees you’ll never see a Twitter emerge from Australia.

What the Investors like

In contrast: the investors at Echelon seemed united in “traction trumps revenue” (at least in lip service) . This is much more like Silicon Valley thinking and probably fuelled by the ubiquitous penetration of WhatsApp in Asia. Everyone uses WhatsApp, Facebook is seen as a lumbering nuisance but WhatsApp’s lightweight utility is what is used for business and social. So when it exited for $19 Billion everyone takes notice.

This kind of attention hints of bias to B2C as an investment preference ahead of B2B/Enterprise startups. Most novice angels fund what they understand and selling B2B products usually emerges from deep understanding of an sector need that is often esoteric to the uninitiated. This is where Silicon Valley investors have an advantage. They (VCs mostly), see enough deal flow and portfolio company activites to know the problems and spot the emerging solutions.***

The Singapore scene

Closely coupled with the investment community is the various government support programs. There are $50K grants for bootstrapping startups and there are co-investment mechanisms as well. I don’t profess to know all the acronyms or programs but its clear the government want innovation at the centre of the new economy – this is where the “Grantreprenuer” phenomenon comes from but to me this is generosity fostering a long-game. Contrast this with the current Australian Government “Commission of Audit” who can’t see past a 24 hour news cycle to drive a mandate beyond their own electoral defensibility strategy.

My 3 goals for visiting Echelon were documented by Phil at Pollenizer. As you can tell I’m seriously investigating whether StreetHawk should remain an Australian company**. From Echelon its clear that investors don’t want to invest in Australian domiciled companies – Singapore provides a far more attractive Capital Gains tax regime in comparison to Australia’s punitive approach to success.

But Singapore is challenging in other ways:

a) Its an expensive town. The locals are toughing it out with increasing living costs especially if you have school age kids.

b) Skilled tech people are in short supply. New employment conditions are coming in August that make this more challenging. In recent years programmers from Vietnam or Thailand or Indonesia could make a great wage in a funky startup but still at a discount to a local’s rate. With the new conditions, I hear salaries will have to be ‘market rates’. Some commentary around this has to do with controlling the influx of hospitality staff but affects the tech sector too. Next door in Malaysia they have some pretty aggressive incentives that are worth considering.

So its ironic that many of the challenges of Silicon Valley are emerging in Singapore before the tech sector has had a chance to get the exits and create wealth. Its hard to tell if this will stifle innovation.

There is no doubt that Singapore is setting the lead for region through the combination of government support and vibrant investor ecosystem.

Mobile First

Another takeaway is a reiteration of earlier post about Singapore and Hong Kong. It is totally “Mobile First” in Asia – of the stands at Echelon, I would estimate that 50-60% were delivering Apps as part of their solution. Needless to say StreetHawk was very well received by the solutions that were launched and were aware of user retention problems.


I had an amusing response from one startup that said they didn’t need anything like StreetHawk because “we’d be looking to grow our app in a native way.” and “We’re going for organic growth”. This is a recurrent theme with immature startups, they assume: “If we build it they will come” – but whats more true is “if you build it they will leave” – customer retention is not considered important or understood – as I mentioned earlier our delusions that users will love our product as much as we do is a major barrier to startup success.  Just by adding StreetHawk in our FREE monitoring mode this App owner would be able to understand what user segments he has and be able to understand where his users are losing interest.

Perhaps he thought StreetHawk was an advertising plugin…..

** I moved ThreatMetrix to the US because that was where the customers were. There was not enough (at the time):

    • e-Commerce in Asia
    • e-Commerce fraud in Australia.
        IOW – We needed to build the business where the actual need was.

** Its got a lot better in 2013/2014 for accepting international payments (not at the behest  of the banks but because of US and Australian startups doing the hard-yards) – which is a pre-condition to actually growing a SaaS business.

*** That said: the winners of the pitch competition were B2B.