Ansh A. Hi, I’m on the same team as 태수 and I’m following up on this question while he’s unavailable. Thanks again for the suggestion! I understand your point about using the first Pageview event to build charts based on event properties instead of relying on user properties. However, I’m concerned that this approach may not fully work for our use case. For our marketing team, UTM data needs to be handled similarly to user properties because that’s how their current reporting and aggregation workflows are structured. If we rely only on Pageview events, it would require them to significantly change their existing processes, and some of the aggregated views they need can’t be easily replicated using event-level data alone. In that sense, relying solely on Pageview events might not provide the flexibility they need. Given these constraints, it seems difficult for us to adopt the Pageview-only approach. One idea we considered was identifying anonymous users with a generated distinct ID (while not attaching any real user data), so that our marketing team could still filter based on whether a “user_id” exists or not, and then later merge the IDs once the user logs in. What do you think about this approach? (Although I know the documentation generally advises against this.) I only read the docs yesterday, so please keep in mind that my understanding of the MP service is still limited.
