Track project events #1364
Track project events #1364
Conversation
|
@joshsmith please let me know if these changes match what we discussed in #1307 . |
There was a problem hiding this comment.
This is generally moving in the right direction, though refer back to this comment I had about the event names needing to change to be explicit about the directionality:
This means we'd actually rewrite the events as
Membership Requested (Project)andApproved Membership (Project)from the perspective of the project. But we would also track aRequested Membership (User)andMembership Approved (User)from the perspective of the user.
| """ | ||
| @spec get_project_id(CodeCorps.ProjectUser.t) :: String.t | nil | ||
| def get_project_id(%CodeCorps.ProjectUser{project_id: id}), do: "project_#{id}" | ||
| def get_project_id(_), do: nil |
There was a problem hiding this comment.
I would move this up above get_resource just to keep things alpha-ordered. We try to generally alpha-order things for quick scannability.
There was a problem hiding this comment.
This is resolved, but github did not mark it outdated.
Tracking of project user events was moved to project_user controller. This change allows us to use existing tracking api without need of passing additional arguments like current user or action to SegmentTraitsBuilder.build/2 that arent needed in other explicitly tracked events.
|
I added direction to tracked events. I moved project user tracking to controller. It allows us to create events name and payloads without changes to analytics api, which wouldn't be possible if we kept tracking in plug |
|
@iref That was a good call. We're actually gradually shifting away from the plug and and adding explicit tracking in controllers in other places as well. |
There was a problem hiding this comment.
Looking at this further, I'm not so sure we should be tracking an event identifying as a project.
The way I see it, from the project's POV, we should still track which user (project admin or owner), approved the membership, or invited a user.
We know which project it happened on from the traits themselves. If we suddenly start recording events triggered by users which are actually project records, our segment dashboard will become confusing.
@joshsmith What do you think?
|
@begedin you're misunderstanding the problem that led to this. Please read #1307 (comment) |
|
@joshsmith I assumed, incorrectly, that it would be possible to define a funnel which does not revolve around the From what I can tell after looking into it more deeply, that isn't possible, so I guess this is our only option. Since, with #1351 we also have membership invites to projects, I guess we'll have to do something similar there. I'll add a comment to that PR about how I think we should do it. |
begedin
force-pushed
the
develop
branch
10 times, most recently
from
488d755 to
46dfe17
Compare
begedin
force-pushed
the
develop
branch
8 times, most recently
from
e075407 to
6d6cc63
Compare
|
Did you get a change to review changes? Is there anything else I should improve before merge? |
|
@iref sorry for the delay on this. We had some things to tace care of before merging this one. It looks good to go to me 👍 |
|
No problem. I just wanted update to make sure that I didn't forget anything. :) |
What's in this PR?
Segment plug tracker now also tracks events for project ids if id is extractable from request resource.
There is more work to be done. Mostly to add
acceptorproperty inApproved Project Membershipevent. This change might require passing of optional current user toSegmentTraitBuilder.buildReferences
Closes #1285
Progress on: #927