Referrer information in Alexa launch requests

amazon-alexa

#1

I recently made an interesting observation in the logs of my voice game Mau Mau: There are apparently different sub-types of launch requests! :microscope::man_scientist:

Here’s the (request property of the) default launch request:

{  
    "type":"LaunchRequest",
    "requestId":"amzn1.echo-api.request.placeholder",
    "timestamp":"2019-05-16T12:45:52Z",
    "locale":"de-DE",
    "shouldLinkResultBeReturned":false
}

and here’s the new and interesting one:

{  
    "type":"LaunchRequest",
    "requestId":"amzn1.echo-api.request.placeholder",
    "timestamp":"2019-05-16T13:04:01Z",
    "locale":"de-DE",
    "target":{  
        "path":"",
        "address":"amzn1.ask.skill.placeholder"
    },
    "metadata":{  
        "referrer":"amzn1.alexa-speechlet-client.DOMAIN:A2S"
    },
    "body":{},
    "payload":{},
    "targetURI":"alexa://amzn1.ask.skill.placeholder/",
    "launchRequestType":"FOLLOW_LINK_WITHOUT_RESULT",
    "shouldLinkResultBeReturned":false
}

So far these two types are the only ones I’ve seen, but it seems like there might be other possible values of launchRequestType than FOLLOW_LINK_WITHOUT_RESULT.:thinking:

My hypothesis of where this new and extended kind of launch request comes from: Alexa’s own Skill recommendations after quiting another Skill. I personally have the very good fortune of Mau Mau qualifying for this strong discoverabilty mechanism where Alexa says something like the following after exiting one Skill:

Because you played Movie Quiz, we recommend another popular game Skill called Mau Mau. Do you want to try it?

In the particular case of Mau Mau, about 58% of launch requests have this extended type, whereas the rest is the default type. If you’re using AWS Cloudwatch Insights and log your request JSONs can find out by a query like the following:

fields @timestamp, @message
| filter @message like /LaunchRequest/ # --> Filters all launch requests
| filter @message like /launchRequestType/ # --> Filters only the extended ones

So, we’d love to hear if you also get launch requests like these, and maybe other types we haven’t seen yet? For example, I could imagine that if you launch a Skill via an utterance that is not a launch phrase (like ‘Alexa, let’s play a game!’) you might get another different type of launch request.

As a related question: In how far would you say this insight is actionable? Do you think it makes sense to react differently to users that have been referred from another Skill? Looking forward to hear your thoughts on this!


#2

That’s very interesting! Has anyone else seen something different than FOLLOW_LINK_WITHOUT_RESULT so far, maybe @gshenar or @marktucker?

Also, has anyone ever seen a different referrer than "referrer":"amzn1.alexa-speechlet-client.DOMAIN:A2S"? Is A2S maybe short for something? Ask to S...? Might be a stretch


#3

Thanks @jan! I’m also super curious to hear any further insights on this (one of them below). I could imagine that the referrer attribute A2S is short for “Alexa to Skill”, because it’s Alexa that refers the user to the Skill - Maybe in contrast to a hypothetical S2S, “Skill to Skill” where one Skill directly refers the user to another Skill, as it would be the case for Skill connections. :thinking:

In order to make discovering other attributes easier, you could use the following Cloudwatch Insight command:

fields @timestamp, type, shouldLinkResultBeReturned, launchRequestType, metadata.referrer, target.address, targetURI
| filter @message like /LaunchRequest/
| stats count_distinct(type), count_distinct(launchRequestType), count_distinct(metadata.referrer), count_distinct(target.address), count_distinct(targetURI) by bin(1h)

However, the only interesting thing I found here is that during certification the Skill receives some launch requests without the shouldLinkResultBeReturned property. :nerd_face:

On Twitter, Alexa Champion Eric ‘Greybeard’ Olson contributed some insights to this topic! Hoping that he doesn’t mind, I’m copying his tweets here in order to preserve them for posteriority:

So, there’s at least one other different property value for launchRequestType beside FOLLOW_LINK_WITHOUT_RESULT! Let the speculations on the interpretation of these values begin! :woman_office_worker:

Finally, Eric has a great Cloudwatch Insight tip:

image

Because it’s such an excellent tip, I give it to you here (slightly modified in case you only log the request part of the full request JSON like me) for easy copy-and-pasting:

fields @ timestamp, @ message
| filter type = "LaunchRequest"
| stats count() by bin(1d), launchRequestType

#4

Ah yes, this makes a lot of sense. Maybe Skill connections will come with a huge bang after all


#5

Wonder if Amazon’s latest announcement about Cross-skill conversation during Re:Mars has something to do with this