Complete tracking events

[rehanvdm]

The firehose and backend API calls are all done, it just needs testing and documentation. Oh and a frontend 😅. Yes, would need a quick design in Excalidraw maybe.

[tomharvey]

Happy to test and document this. Is there a backend PR that gives me a sign of what the API looks like? Can probably get started from that.

[rehanvdm]

Sorry for the lack of detail, did not think anyone would want to pick it up :). That would be great but this one is going to be a big one that involves a lot of refactoring as well. Let me try to break down the work, let me know what you think.

Firstly within this project, you will see that the ingest endpoint is already defined in src/src/backend/api-ingest/v1/event/track/index.ts and that it is very similar to the page view. This is by design, one tracks pages views and the other one custom events.

Below is the OpenAPI spec for the api-ingest that is generated with scripts in the package.json because you asked what the API looks like. That is then copied to the frontend client project to generate types from and then used there. When you work on the api-front now, you will not interact with the OpenAPI spec at all, it only uses tRPC.

The difference between the page and the event is that with the event you can pass a data property. This property is optional and defaults to 1. The idea is that the backend (api-front) when showing the events does a sum on this field.

The backend the frontend uses (src/src/backend/api-front/routes?) still needs to be done. It will have almost identical endpoints to the page type at (src/src/backend/api-front/routes/stats).

Because the page view and event tracking is so similar, a lot of what is written can probably be reused. The idea is that the frontend also looks similar. Most of the frontend blocks are components on their own that should not be too difficult to refactor for the usage of both types. So I would create a folder called event_stats or something similar here.

Then the page_stats would first need some love. The top part that selects the sites and dates has to move to app.vue because it has to be present on both pages and we don't want to rewrite that. There also needs to be top-level navigation between the page stats and event stats, for now we can just use tabs. BTW we are using Element Plus Vue, because I don't have time to create frontend components and align CCS, it is not the focus of the project so I tend to use off-the-shelf things and keep custom things to a minimum.

Then for the events page, I was thinking of something similar to this. Basically the same layout as pages just different values. But more than open to suggestions if you have.

---

Before you begin with the API for the frontend though. We need to uncomment the tracking function in the client library and add usages for it + document it in the README.

Actually, this would not stop you from doing the work here, you could run the tests in this project and it should generate some event data for you to use while developing. So this work can be done in parallel. I created a separate ticket for that here https://github.com/rehanvdm/serverless-website-analytics-client/issues/11

[rehanvdm]

Add an event category that is optional.

Then in the UI it will be shown as a tag in front of the name. Clicking on the tag will filter all events with that tag. Useful to group the outbound and 404 links. Which will be system defined and protected, but the user can add any he wants, this is a dynamic field

[rehanvdm]

This is pretty much done https://github.com/rehanvdm/serverless-website-analytics/pull/59 but I am still to self-review the PR. Feedback and/or PR review are more than welcome. This is what it looks like atm, pretty similar to the page views.

[rehanvdm]

@tomharvey this is now live. You can play around with it on the latest version, let me know what you think :)