Add userId field in track event

[karinacrispim]

Is your feature request related to a problem? Please describe.
We are using this library in a Kotlin JVM server-side Application. The project has Amplitude as a destination. We noticed that some events are being added to the wrong users in Amplitude, invalidating the analysis. In the implementation, we call identify and thentrack event of the respective user.

To get around the situation we already tried to call flush and reset after the track, but we still have the problem.

We noticed that some track events don't have the userId.

Describe the solution you'd like
We would like the track function to receive the userId as an argument. That way we wouldn't need to call identify and the event would be allocated to the user correctly.

Additional context
Other segment libraries for server-side applications already have this functionality.

[wenxi-zeng]

@karinacrispim thanks for bring this to our attention. we actually received similar request before, but we don't have a decision on this yet, since this change will impact the mobile-side interface too. we probably will include this feature when we extend the sdk to kmm. in the meanwhile, you can write a simple plugin to achieve the same functionality:

class UserIdPlugin: EventPlugin {
    override val type: Plugin.Type = Plugin.Type.Enrichment
    override lateinit var analytics: Analytics

    override fun track(payload: TrackEvent): BaseEvent? {
        val event = super.track(payload)

        if (event is TrackEvent) {
            event.properties.getString("userId")?.apply {
                event.userId = this
                event.properties = updateJsonObject(event.properties) {
                    it.remove("userId")
                }
            }
        }

        return payload
    }
}

add the plugin to analytics and then use it like this:

analytics.track("test", buildJsonObject {
    put("userId", "YOUR USER ID")
    // other properties
})

I will close this issue for now since this feature is already on our radar internally. feel free to reopen it if you feel the workaround does not address your issue