Thanks for reaching out here @Mikalai. I found this related thread. Please let me know if you need additional assistance. 

Thanks for the reply. I've checked that thread, and unfortunately, it doesn't provide any options on how to fix my problem. I suppose the issue comes from a mapping mismatch, but there is no additional information on what needs to be changed.
 

@Mikalai Definitely agree that this error message isn’t detailed enough. Will be sharing feedback with our engineering team on this.

In order for Amplitude to stream events into Appsflyer, each event needs to have an AppsFlyer ID. Can you please double check if the User ID you’re setting for your users on Amplitude matches your users’ AppsFlyer ID exactly?

Here’s the help doc with more details on how to set up this integration.

@ttan Thanks for explaining, I didn’t set User ID initially. So, after your reply I replaced it with user property, which is sent by AppsFlyer, it is called “lAppsFlyer] appsflyer id”. Though, now there is an error on the “Verify connection with test data” step. Does it have to be a Custom user ID created by the app developer like in the example here, or it can be any existing property?

@Mikalai Hi! Apologies for the delay in answering you, I’ve sent this through to our support team to get their eyes on your question.

Update on the topic: 

For the integration, error message on the Debugger tab says "message": "Input has missing fields that the template expected: input.os_version". 

OS version is required by AppsFlyer. It is the os parameter in AppsFlyer. Send Event.

Hi, thanks for your help. I have added os parameter, but events are still missed in AppsFlyer.

Hi, Amplitude events are still missed on AppsFlyer. Would be glad for any update on my case! Thanks

Hi @Mikalai ! To confirm, did you get any error messages after inputting the OS parameter? Or there’s no longer the error but you still don’t see events in Appsflyer? 

I took a quick peek at your data and it doesn’t seem like you have had any events where appsflyer_id is not none since you added the OS parameter (at least since the beginning of May). That might be why you aren’t seeing any events still since there aren’t events that fulfill the condition you set in your Appsflyer Event set-up. 

I’m seeing the same error, even when adding “OS”: 

Input has missing fields that the template expected: input.os_version

BTW, congrats to @Esther Trapadoux and the entire Amplitude community team. This is the first time that a google search for a real-world Amplitude question/issue brought me straight to an existing thread, which is a huge milestone.

🥳

When placing into the SAMPLE payload “os_version”: “iOS”, the error message goes away for the “Test Event” widget.

However, I don’t see how this is possible within the amplitude UI that we’re provided since os_version isn’t a mapped Appsflyer property. Do I need to create a completely new property “os_version” that is a duplicate of the existing “os” - that smells bad.

See below - “os_version” doesn’t appear as a selectable/mappable appsflyer property. My suggestion is that Amplitude adds that mappable Appsflyer property to the integration ASAP as that seems to be the reason why this is now broken. I believe this could have been caused by Appsflyer team suddenly requiring in the payload AFTER this integration was already released.

Another note: I’ve already filtered my events to make sure that I’m only sending iOS associated amplitude events to my iOS Appsflyer App. At first I thought that perhaps that was the issue - where the error message was missleading and that it was actually wanting to make sure that I wasn’t firing Android Events to an iOS Appsflyer App...

I’ve thought of another reason why this might not be working - the events I’m attempting to stream from Amplitude to Appsflyer are fired from the Back-End, NOT from the Front-End SDKs. Could it be that this streaming configuration isn’t expecting events fired from backend and thus is throwing some complaints about structure it’s used to seeing?

I’ve just confirmed that FE fired events are being streamed to AppsFlyer successfully.

I believe that the error message “Input has missing fields that the template expected: input.os_version” that we’re being shown is just a sliver of the actual problem: Events fired from our backend are not structured using the Amplitude FrontEnd-SDK, which automatically populates default fields.

The developers of this integration are expecting the additionally added event/user properties that the SDK provides. I’m would hazard a guess that this error is effecting anyone who is attempting to stream backend events OR who has turned off default tracking of User properties on their FrontEnd-SDK integration (See here: https://help.amplitude.com/hc/en-us/articles/115002380567-User-properties-and-event-properties ).

This could easily be fixed by the Amplitude identifying the TRUE list of required event/user properties and allowing the client (us) to map for them manually.

I’m going to have my team try and fire backend events with additional properties like “OS” and “Platform” that are usually added by the amplitude FrontEnd-SDK. I have a feeling that these will show up as “Custom” properties instead as “Amplitude native” properties - this could be another issue that needs addressing.

I don’t see why “os_version” would be a requirement from AppsFlyer - so I would also suggest investigating why this has been thrown in as an added hidden requirement for event streaming configuration to work.

In the meantime, @belinda.chiu, if you could highlight the properties that are actually required by the developer’s code (including hidden requirements like Amplitude’s default “OS” property) - That would help us move much faster in making sure our backend events are structured properly instead of just guessing and seeing what error message is next fired:
 

I would have assumed that the only required property would have been the custom added property “appsflyer_id”… but it seems that isn’t the way this was developed.

Or alternatively - Sharing a view of the source code for this streaming configuration, then I (or another engineer) could identify what exactly is going wrong and proceed (probably within a few minutes). - Just waiting for the amplitude team wander over to this issue and make some updates seems like it would take a bit too long

Thanks @Isaac Dressman for the info.  I’m looking forward to the Amplitude response too.  
 

fwiw, the events I was trying to stream were from our front end Android SDK implementation, but I have also not yet integrated the appsflyer SDK, so there would not be a user id match on appsflyer’s side, which idk whether it’s required. 

Hi @Isaac Dressman, 

Thanks for your report here. The AppsFlyer OS field is required and we automatically map Amplitude OS version (os_version) to it. This does not need to be (and cannot be) selected as a mapping. If it does not exist on the event attempting to be sent, it will fail.

The default for the sample payload is static and will not necessarily work out of the box for the tester. You may need to add in required mappings or others fields. For AppsFlyer, os_version and an Amplitude field or user property corresponding to the AppsFlyer ID will need to be added to that payload for it to succeed. Even if the tester fails, this does not necessarily mean that there is an issue in the configuration.

The error shown in the screenshot is because os_version is missing from the payload. Same thing with the other similar error in a screenshot in the thread referring to user_properties..AppsFlyer] appsflyer id; in user_properties they need to add ""AppsFlyer] appsflyer id": "some valid appsflyer id".

Currently, there is nothing required in the settings UI form to select anything for OS version. You’ll only need to make sure it is included on the events they are trying to stream, and that os_version is included in the tester payload. This is a mandatory requirement with AppsFlyer’s API.

We’re looking into making this clearer on our end as well as providing better instructions with the event tester, but hope this helps.

Hi Jarren,

If I’m understanding, it sounds like you’re saying I should just ignore the test event failure message (that it’s buggy), since there’s nothing I can do to fix it, but also that os_version is mandatory in for the AppsFlyer API, meaning that Amplitude will be sending the os_version automatically for non-test events? 

Thank you for that note - We’ve updated our backend events to include OS and found that SOME of the backend generated events are coming through as expected. Note that we are no longer getting errors in the debugger - However, not all of the events that should be streamed are getting sent. Our daily checksums of Amplitude VS Appsflyer are about 30% match for backend events (vs 100% match for FE events). We have looked into the events in question and can confirm via a filtered segment analysis in Appsflyer that “OS” and “Appsflyer ID” are being included in these backend payloads. What we find most confusing is that a portion of the backend events are coming through at all - we would think it would either be working or broken.

Have the Amplitude dev-teams tried to use this streaming integration with Async/Backend fired events before? Has this been tested? It seems like a major use-case across many industries, especially that of insurance and fintech where offline events like “money settling”, “application approved” etc are extremely common.

Our dev team had thought that this would be pretty straight forward, but it’s turning into a huge head scratcher. We would love to be able to share our analysis to Amplitude in the hopes that this powerful feature can be improved for all Amplitude Customers.

Hi @Anthony ! 

Correct, you can either ignore the test event failure message or add the parameters into the tester payload before hitting send. The error shown in the screenshot is because os_version is missing from the test event payload. Same thing with the other similar error in a screenshot in the thread referring to user_properties._AppsFlyer] appsflyer id; in user_properties you will need to add "tAppsFlyer] appsflyer id": "some valid appsflyer id" to the test event payload.

To confirm again, there is nothing required in the settings UI form to select anything for OS version. You only need to make sure it is included on the events you are trying to stream, and to prevent the error from showing up, that os_version and other properties are included in the tester payload.

As for improvements to make this clearer, the Engineering team has in mind to have better defaults and clearer error messages for the tester, but they just haven’t been prioritized yet due to competing priorities. But they do plan to update our docs for this integration in the meantime to: 

• Make it clear that Amplitude OS Version is required.

• Provide instructions on how to use the event tester, including exactly what must be added to the default payload to make it succeed for AppsFlyer (how to add os_version and the mapping/property for AppsFlyer ID).

One of our data scientists believes they found the discrepancy (after 2 weeks of head scratching).
Appsflyer organizes events NOT on the date the event was fired, but rather the date that the user was created. This makes sense since their focus is to see what events were associated to which cohort.
This means that when performing checksums for backend fired / offline events, if there is a significant amount of time in between the user being created and the backend event being fired, you will need to widen your search range significantly for Appsflyer to reflect that event being fired with said user.

We believe this means our backend events are fired properly and that this plugin does work for backend fired events - but the process of performing a checksum is a massive headache. We were able to 100% confirm by creating test BE events that fired immediately after a test user was created and confirming that they were coming through with a 1:1 match.

I’ll reach out to Appsflyer asking them to expose a “events fired” log (by event fired timestamp) in order to make this much less of a headache for other dev teams in the future.