-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Context #23
Comments
Adding this as a third parameter to the track calls.
I'm a little unclear how how this should be added to
I'm also a little unclear on why you included a PHP array above that has a top level key |
Sure thing, we're actually just about to change the way this works for the Javascript library, so here's an updated version for the new API in Javascript only: analytics.track('event', { property: 'something' }, {
context: {
library: {
name: 'analytics-magento',
version: '0.0.1'
}
}
}); The difference is that the The other methods have their analytics.identify(userId, traits, options);
analytics.track(event, properties, options);
analytics.page(category, name, properties, options);
analytics.group(groupId, traits, options);
analytics.alias(userId, options); So each time you see {
context: {
library: {
name: 'analytics-magento',
version: '0.0.1'
}
}
} |
The PHP library (and other libraries) are structured slightly differently, since they are stateless. They have all of their parameters as keys in a top-level array, like so: Analytics::track(array(
"userId" => "user",
"event" => "event",
"properties" => array(),
"context" => array(
"library" => array(
"name" => "analytics-magento",
"version" => "0.0.1"
)
)
)); And all of the PHP calls have the same top-level structure, so they would all put Does that make sense? Let me know if you have questions. |
Actually, I just realized, ignore the PHP stuff. I think you're exposing a Magento model that wraps our PHP library? I just realized we shouldn't actually be exposing a proper PHP API, we should expose it in a way that just adds the calls they make there to the page, like we do with WordPress: https://github.com/segmentio/analytics-wordpress/blob/master/analytics-wordpress.php#L150 |
Ian thanks. One last question — what should I be passing in on the
Do I just do this?
Or will that be interpreted as the category form
|
For those ones, the API will handle overloading for you if you want, so for example: analytics.page(name, properties, options); Works fine. But the nulls also work if that's clearer for you. Only reason Does that make sense? |
Yup, makes sense. All calls ( |
Forgot about the need for this one, but there's a field for all API calls to our API called
context
. And one of the things we do is that for each library we include library-specific information there. For Magento we'd want to include:We use that internally for metrics and to do smart automating things in support and such. We'd want to add this automatically to all client-side and server-side calls from the extension
In analytics.js the third parameter to most of the calls is the context:
In PHP it takes a
context
key in the top-level array:The text was updated successfully, but these errors were encountered: