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
Tracking API: provide a new JSON Tracker API #4625
Comments
See also #6000 Build a RESTful API for Piwik |
Hi @mattab , I've landed there from matomo-org/developer-documentation#28 I think you should consider using POST request for the Tracking API. Maybe you can also allow GET requests in case the client cannot do POST requests (Google Analytics does that), but the better HTTP verb to use in this case in POST (see here). Some other thoughts:
I would name it Also, I don't know if you're familiar with JSON Schema, but it may be a good way to validate such user-submitted data. Best, |
Hi @mattab, Is this feature planned anytime soon? It is an issue when trying to integrate Matomo as a 'destination' in customer data platforms, particularly when it comes to authentication, which is required to forward the correct timestamp and IP of an event in such cases. For safety reasons, it's better to forward the It would also be more user-friendly to build variable request payloads, instead of needing to worry about concatenating all query parameters followed by URL-Encoding. A great plus for people who cannot code and construct their requests within a CDP, filling the according key-value pairs into text fields. That part of this comment is a detail, of course, but making it easier for no-devs to use your tracking API, why not (just a thought). But the problem with the authentication described above technically forces us to make a roundtrip to our own server just because of the Content-Type and the |
@fulstadev Thanks for your feedback! I was wondering about this: |
@mattab Sure, no problem. If the Matomo API could understand JSON payloads, you could use the default masks these tools often offer, in a simple way (the 'webhook URL' would be the URL representing a matomo tracking API call, and what you see in the image with the '$'-prefix are (JSON) variables from the event incoming into the CDP. But because Matomo only understands the parameters via URL, you instead have to prepare the URL using sth like: This is fine as long as you don't have any spaces or whatever, which is when URL-encoding is needed. The tool we use actually does not offer a URL-encoder for the generation of the webhook URL to be used as data pipeline destination. Consequently, the only solution we see is to generate the URL (url-encoded) to be used for the matomo tracking API call entirely within our backend, and send that URL along as attribute of any event we send to our CDP. Then we can use the ready URL within the CDP, and create an automated pipeline. But note that this still does not solve the issue of the Another thing is that Matomo Tracking API URLs quickly become long. If no-devs have to use sth like 20 placeholders within it, join them with ampersands, and then watch out that everything is url-encoded (if the code permits it), it can be tedious to build this with pure placeholders, again for non-devs. It also happened to our devs already that a pretty long Matomo tracking URL failed to be executed because an ampersand was missing in front of one of the placeholders, and the resulting matomo request was treated as a So we're not sure how you weigh these issues, but the token issue is of greater importance for us..? Thanks anyways for your quick reaction! And please don't misunderstand this post, we really appreciate matomo and its features, a lot. A last note regarding the UX with CDPs though is that we've been working with more than three of the rather big players, and they were not offering an out-of-the-box integration with matomo, as with other analytics tools. Hence the only workaround for a data pipeline through to matomo is an actual webhook endpoint as data pipeline target (probably already at the dev-level here). We just think that a JSON-version of your API would make that integration much easier. |
Thanks for the feedback @fulstadev, that's appreciated! |
Our tracking API is fully documented at: Tracking API - tracking users analytics
It is also fully featured, and yet still a bit unstructured. Because we have added parameters one after the other when they were needed for useful features, now we realize that they could be named better, and be more structured.
Now that JSON has gone mainstream, it is natural to provide a pure JSON proxy to our good old named parameters. In the making, we could introduce structure in elements like events or ecommerce interactions (define each as a JSON object).
New API names proposals (to be discussed)
The text was updated successfully, but these errors were encountered: