Forum Replies Created

  • Sophia

    Member
    5 July 2023 at 2:29 pm in reply to: Unassigned Refunds in GA4 Traffic Acquisition Report

    To connect refund data beyond the 3-day window using GA4’s Measurement protocol, you’d need to keep a consistent identifier (like transaction ID) between the purchase and the refund. This will let you link the two events even after the 3-day window. If you want to understand acquisition channels leading to most refunds, a programmatic solution in GA4 might not be enough. Using a more advanced data analytics tool like BigQuery or LookerStudio to analyze refund data in relation to other metrics might be a more effective option. It’s true that GA4 doesn’t preserve the full transaction attribution in the report, so a detailed data analysis using these other tools may provide more clarity.

  • From looking at your initialization, I see that you’re using gaOptions for user properties. However, gaOptions is actually used to set up fields that control how the pageview hit is processed, so it’s not the right place to put user properties.

    To send user properties, you should use the set command, which is used to set user-level and session-level dimensions and metrics. You can use it similar to how you’d do in Google Analytics’ JavaScript (gtag.js). It would look something like the following:

    `
    ReactGA.set({ ‘user_role’: userRole });
    `

    Keep in mind that you first need to create these user properties in Google Analytics and use the exact name you set there. In the new GA4 property, you’ll need to set it up under User-Scoped Custom Definitions.

    However, as per react-ga4 official documentation, please note that set command is not currently supported. Therefore, you might need to leverage gtag.js directly or use another library that supports GA4 user properties if this is mandatory for your application.

    This is a rapidly developing area – make sure you are on top of the latest releases and checking the react-ga4 GitHub page for any updates.

  • Cross-domain tracking in GA4 can be a bit tricky with separate GTM and GA4 setups. The official documentation notes that you need a shared data stream, as it helps Google Analytics understand that user interactions across the two domains are from the same user session. However, this doesn’t necessarily mean you need to blend your data.

    Creating a new GA4 property for cross-domain tracking could be effective. You’d want to add a config tag with the new measurement ID to both GTM containers. The idea here is to have a separate stream of data that’s only for cross-domain tracking. You don’t need to limit this tag to only the event triggered by a click on an outbound link from domain A. It should track all user interactions across both domains.

    For domain B, and also for domain A, you should certainly assign the config tag with the new data stream to all events. This will enable GA4 to follow the user as they move between the two domains and build a complete picture of their behavior. Again, this doesn’t necessarily mean that you’re blending your existing data. You’re just creating a supplementary stream that specifically tracks users who move between the two domains.

    Remember, you aren’t losing any of the individual data from each website setup. This data is still tracked individually by each domain’s unique GTM and GA4 setup. The new GA4 property is in addition to, not in place of, your existing setups. It’s simply a way to give you insight into user behavior that spans both domains. Just make sure to keep all your events, conversions and other configurations consistent between the domains.

    If you still have queries or run into issues, don’t hesitate to seek advice from a GA4 implementation specialist or attend one of Google’s dedicated training sessions.

  • Sophia

    Member
    5 December 2022 at 8:44 pm in reply to: Mysterious city codes in GA4: What's going on?

    It seems like you’re facing an unusual situation. Google Analytics 4 (GA4) showing a number instead of a city name might appear strange, but there could be possible explanations for it. A potential reason could be that the number you’re seeing is actually a ZIP code. In your case, this might indicate a small or less-populated town in Germany that isn’t registered with a recognizable city name in the analytics API, hence it’s showing the ZIP code. If you’re certain that no one from Germany should be accessing your application, the traffic could be from VPN users or perhaps bots running from German servers. Since you’ve already taken serious security measures, you could wait and see if the unusual data persists or cease after these changes. If it continues, it might be worth getting in touch with Google support or further investigating network logs and traffic sources to identify the cause.