Share common installationId

[duckworth]

The installationId that is sent up to lambda https://github.com/aws/aws-sdk-android/blob/a335077bb6a77a4bfce9b9263850d010518c5bce/aws-android-sdk-lambda/src/main/java/com/amazonaws/mobileconnectors/util/ClientContext.java#L95 is completely different then the clientId that the mobile analytics SDK sends up https://github.com/aws/aws-sdk-android/blob/a335077bb6a77a4bfce9b9263850d010518c5bce/aws-android-sdk-mobileanalytics/src/main/java/com/amazonaws/mobileconnectors/amazonmobileanalytics/internal/core/idresolver/SharedPrefsUniqueIdService.java#L46.

Would be great if these could be the same so that custom events could be reported by a lambda function and have them associated with the same client_id on the backend as the events reported by the client device itself.

[fosterzhang]

There are a few concepts here. For Amazon Mobile Analytics, the app_id is generated for you during the app creation wizard. The app_id is used to group your data in the Mobile Analytics console. The client_id is a generated value by MobileAnalyticsManager. It's unique per app_id. It's used to identify the app under the given app_id. Amazon Mobile Analytics allows you to have multiple app_ids in the same app to route analytics data to different destinations. That said it's possible to have multiple client_ids and client_id isn't unique in the app as a result.

The installation_id is intended for AWS Lambda and is aiming to uniquely identify an app for the SDK. It is generated per app installation and will be persisted till the app is removed or data is cleared. Regardless how many AWS Lambda clients you have, there is only one installation_id per app installation. This value is recommended for tracking purpose in AWS Lambda.

Currently these values aren't associated due to the differences. If you want, you can send the client_id of Amazon Mobile Analytics to Lambda and form an connection yourself.

For more information, please see Amazon Mobile Analytics documentation.

[duckworth]

OK, I understand they have differences. I guess my higher level point is that using Cognito, Lambda and MobileAnalytics together has been challenging and is lacking in cohesion when it comes to identifying specific device installations.

From what I can gather, Cognito represents a User and has no device identifier mechanism. Analytics will send you the Cognito IdentityId all the way to the backend (S3/Redshift) but it associates it with the client_id. Lambda conveniently provides an authenticated Cognito Identity but sends up installation_id. Like you said we can send up client_id manually as a parameter, but it feels like this should be in the context, since all the other data is there (including app name, version, etc.). The other challenge is that trying to submit an event to Analytics on the server from Lambda on behalf of the client is a challenge, as there is no way to submit the Cognito Identity Id to MobileAnalytics so that it shows up in the same attributes on the backend (have to force it into a custom attribute) see aws/aws-sdk-mobile-analytics-js#8.

Also, It would be great if the installation_id would be exposed in the client SDK in a public method. All we could find was getting the the whole ClientContext toBase64String and parsing it out.

[fosterzhang]

@duckworth I see your point here. I'll keep it in mind in future improvements. I'll also think about exposing the installation_id as you suggested. Stay tuned.

[fosterzhang]

This has been added to v2.2.10 release. Please check out the release notes.