A Deeper Dive into Alexa Push Notifications

on October 7, 2017 at 9:00 am

This post originally appeared on the 3PO-Labs blog which can be found here.

As mentioned in our previous post, we’ve had the opportunity to play around with the new Alexa push notifications feature for some time now. While the exact implementation details on the Alexa Skills Kit side are still not public (and therefore not something we can talk about yet until the public beta goes live), there are enough consumer-facing pieces that we CAN talk about that should be of interest to folks starting to think about their push notification use cases.

Overview of feature

First lets start with a rundown of the feature itself, for those who haven’t had a chance to use it yet on one of the few applicable skills. Notifications happen for normal, custom skills – this isn’t a new type of skill or anything along those lines (AstroBot was a custom skill well before notifications existed, for example). Amazon has taken to referring to the notifications as “opt-in notifications”, and that’s an apt description, as a custom skill can exist and be enabled by a user without having any capacity to push to that user’s notifications queue. Like Account Linking, List permissions, or Device Location permissions, a user will be prompted upon activating the skill to decide what capabilities to grant to that skill (and the available list is of course shown on the skill screen before the user chooses to enable it).

Note that the possible permissions are always listed on a skill’s base page, even before enablement.

As you can see in the image above for AccuWeather, the modal now contains an extra permission request at the time you enable it, as well as a few details about how the feature works. One really interesting thing to call attention to is that the Device Address permission seems to default to the “on” position, while notifications defaults to “off”. This is very much in line with the way Amazon is messaging this feature as “opt-in notifications”. The play here is obviously to minimize concerns that folks might have about losing control of when Alexa interacts with them. Amazon has done a lot of the heavy lifting in this regard, but there are still a few things to call attention to in terms of what we’ve ascertained to be “best practices” for the new paradigm.

TimeZones/DND

The first thing to consider is that you could be sending notifications to anywhere in the world, and as such to any TIME in the world. A user is able to set up their “Do Not Disturb” preferences for notifications/messages on each device they own, but out of the box this value is not set. Most users aren’t going to realize this is a problem until the first time they get woken up in the middle of the night by a flashing Echo Dot.

Further, right now the DND feature is a sledgehammer – there’s no ability to apply a sleep mode to specific skills while granting other skills the ability to notify. A case where this might be relevant is for something like AccuWeather. While most people don’t want to be dragged from their slumber to learn that SpaceX is about to launch a Falcon 9 sometime in the next 24 hours, they probably DO want to be awoken if the government issues a tornado or wildfire warning for their area.

This leaves a lot of implementation details in the hands of the developers, then. Do you want to include special safeguards for people in radically different timezones than your notifying software? Want to silence some notifications at certain times of the day, but not others? Want to have multiple DND blocks in a single day? All of these things will need to be implemented as an additional layer in your skill. Further confounding this effect is that there’s still not a good way to simply learn a user’s timezone without asking each and every user to give it to you. A lookup based on the user’s address in the device location API is possible, but there are ramifications therein that make it an unappealing choice.

Overnotifying

Another thing to consider is the question of “how many notifications is too many notifications?”. As a thought exercise, consider this: If you were to not touch your smartphone for an entire day, how many push notifications would you have waiting for you at the end of that day? Now assume that rather than swiftly swiping them away, each of those notifications took you 15 seconds to clear, and you couldn’t be using your device while you cleared them? The image below is a typical “while I was at work” snapshot of the notifications on my tablet…

Really Twitter? Three different notifications that aren’t even about my personal activity?

That’s something like the situation with push notifications on a voice user interface. Listening to each notification is something of a commitment, and thus far there’s nothing equivalent to the little visual cues that you have on a smartphone that might tell you whether or not a given notification is interesting. The takeaway, then, is that as developers we need to set a high bar for when we notify. Anything we push out needs to be perfectly tuned to what the user is expecting. And you can more-or-less put push marketing on the backburner for now (regardless of Amazon’s cert policies), because the disruption factor is almost certainly to get you a flood of negative reviews if you’re abusing the feature for the classic “Hey, don’t forget to check out a new episode of The Orville tonight on Fox or the FOX NOW App” type of message.

Subscriptions (and events)

So, one way to address this issue is to make your notifications more granular and focused. Currently AstroBot supports notifications for “upcoming launches”, but we plan to add a few more types of possible notifications, like “upcoming ISS transits”, as well as “upcoming launches for a specific agency”. When we make these available, however, we aren’t just going to start blasting all of our “upcoming launch” subscribers with news about the ISS. Sure, they’ve granted us permission to send notifications to them, but that’s not what they asked for, and we’re not going to make that decision without their explicit input. We believe that a secondary, skill-specific subscription model is going to be a best practice in almost every case.

The flipside, of course, is that you now have to manage your own subscription model and store user preferences. This is a non-trivial bit of additional work, and not everyone is going to want to take these steps. There’s certainly room here for some third parties to step in and provide services to developers (in fact, we have a few things in the mix already), but we fully expect that there will be a sizable portion of the dev base who decides to either do a lazy implementation of notifications, or just skip them altogether.

Tying into this issue is that there are some weird architectural quirks about notifications that make the need for a solid “user preferences” and “notification subscriptions” mapping for each user important. If you run a skill where notifications are not central to your purpose, you’ll often have users of your skill that are not notification subscribers, but if you are operating notifications off of an “all my users” approach you’re going to end up with a ton of notification triggers aborted at the point halfway through the workflow where it becomes apparent that the permissions are missing.

Even in cases where subscriptions ARE being tracked, this last issue has potential to be a bugaboo, as skill disablement or notification permission revocation are both cases that result in notification triggers that cannot be completed. Amazon has begun to address this concern with their new Skill Events feature, but for the moment that feature is tucked away behind the SMAPI and not available to folks building through the developer console (aka “almost everyone”).

Cert/Testing

Speaking of bugaboos, here’s a riddle. How does certification test a skill that asynchronously starts an interaction with the user? In the case of AstroBot, space launches happen about once a week, and my cron job went off daily at a time of day that wouldn’t have been conducive to most office work schedules. Were they supposed to sit and wait in the hopes that eventually they’d be lucky enough to catch a launch notification?

This is the dilemma we faced the first time we went to submit. Rather than this approach, our idea was to provide an endpoint that the cert team could hit (a simple GET call with a key in the query param) which would simulate our daily cron job going off. Further, we set up a mock launch data provider which was guaranteed to always claim at least one upcoming launch in the next 24 hours. We expect something along these lines to be absolutely standard for the certification process.

The thing that makes this interesting is that it brings into focus the “bait-n-switch” concept, where the service backing the skill is changed after passing cert. For notifications, we sort of have to do this. But does that put Amazon in a weird position, requiring a bait-n-switch for one aspect of the platform but (weakly) forbidding it for others?

That’s a tricky question, and one I’m not sure how the Alexa team will answer. In the meantime, there are some things I think they can definitely build on in the near term that will make the experience better for users…

Things to improve

Disable auto-prompting: This is a feature request I’ve had in with the team since early in the beta. Right now, you choose either “notification permissions” or “no notification permissions”. I propose that there should be a third option “notification permissions, but don’t prompt upon skill enablement”. This may sound weird, but consider a case where a skill is MOSTLY for non-notification use cases. Users who are signing up for the primary use case are going to see a request for notification permissions that they’ll never use, and a big chunk of those users are going to abandon the skill at that moment and never actually use it. This is a well-observed phenomenon in the mobile world when apps aggressively pursue permissions, and it was a big deal recently when Android finally allowed permissions to be requested only at the time they are actually needed. It is our belief that Alexa needs a similar flow.
TimeZones: As mentioned above, managing timezone preferences is a pain, and this has been one of the most requested features for a long time. Obviously device location alleviates this somewhat, but it would be much preferable if we could just know timezone without having to deal with having a user’s personally identifying information (which address certainly is).
Lookup: We can’t talk about this a ton until the API is opened up to everyone, but something to consider is what happens in the life cycle of a notification after it is sent out. At this moment, the “post-send” options are barebones and quite frustrating to use. A little love on this feature set would go a long way.
Users with no notifications-enabled devices: This is something we’re not even sure is an actual issue, since we don’t know how to test it, but what happens when a user thinks they should be getting notifications, but it turns out their Alexa-enabled smart toothbrush (or whatever) isn’t able to do push? Do the notifications just linger and die? Should the user have even been able to sign up for notifications without an applicable device? What’s the right UX here?

So, this is obviously a brand new field, even if there are a lot of useful analogs from the mobile world. The feature itself is cool as hell and will make for some great new capabilities on the platform, but I would be completely surprised if we don’t start seeing a negative sentiment reflected pretty much immediately in the review corpus due to some of the issues listed above. Devs are gonna need to decide whether it’s worth it to risk anti-notification blowback tanking their rankings or not, especially given the considerable investment it takes just to get push going to begin with.

We’re looking forward to seeing how folks address these problems, and indeed, as previously mentioned, we have some thoughts of our own on how to work around the shortcomings and provide additional value beyond just the basics of the feature.

You can read more from Eric Olson at 3PO-Labs. You can also follow him on Twitter here.