You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is there a reason that both identify() and logEvent() are being called in this function? According to Amplitude documentation, identify does not count against monthly event count limits:
However, logEvent() does count against limits. In the web app I'm working on, this means an event is being logged every time the app is re-initialized or a user logs in, and we would like to clean up non-essential events to avoid scenarios where we may exceed our monthly event limit.
It would be helpful if the logEvent call was either removed, or able to be optionally not triggered depending on the use case.
Thanks!
The text was updated successfully, but these errors were encountered:
This is a great question, and I don't have a good answer for you. My hunch is that you're correct in that we ought to remove the logEvent — if consumers of this addon want to also log an event after identifying, they can do so themselves. Let's open a PR to deprecate this behaviour, and slate its removal in the forthcoming major release.
In the
identify()
function in the Amplitude metrics-adapter, I noticed that there is a double-call of sorts being made:https://github.com/adopted-ember-addons/ember-metrics/blob/master/addon/metrics-adapters/amplitude.js#L76-L77
Is there a reason that both
identify()
andlogEvent()
are being called in this function? According to Amplitude documentation, identify does not count against monthly event count limits:https://developers.amplitude.com/docs/identify-api#faq---identify
However,
logEvent()
does count against limits. In the web app I'm working on, this means an event is being logged every time the app is re-initialized or a user logs in, and we would like to clean up non-essential events to avoid scenarios where we may exceed our monthly event limit.It would be helpful if the logEvent call was either removed, or able to be optionally not triggered depending on the use case.
Thanks!
The text was updated successfully, but these errors were encountered: