# See Your Website Traffic on Android and iPhone: Free Google Analytics Setup

Tutorial method recorded September 26, 2026. This public version uses placeholders. It does not claim that your own website is connected until you perform the final checks.

You will connect your website to one Google Analytics 4 property, then view that property's reports from a browser and the official Android/iPhone apps. The phone is a viewer of website data. You do not need to build an Android or iOS app or create Firebase streams for this task. [Google's mobile app overview](https://support.google.com/analytics/answer/12674799).

Standard Google Analytics offers its tools free of charge. Your existing hosting, internet and any separately chosen AI services are separate costs. [Google Analytics](https://marketingplatform.google.com/about/analytics/).

## What you need

- Your live website, such as `https://example.com`.
- A Google account you control, also available on your phone.
- Access to the website's source or supported Analytics integration, and to its hosting account.
- The official Google Analytics app on Android and/or iPhone, installed through the links on Google's app overview above.
- A backup of the current site.

Use your own values throughout:

| Placeholder | Replace with |
| --- | --- |
| `https://example.com` | Your real website address |
| `My Website` | Your chosen property and stream name |
| `G-XXXXXXXXXX` | The Measurement ID generated for your own Web stream |
| `<PROJECT_FOLDER>` | Your site's actual source folder |
| `<DOCUMENT_ROOT>` | The hosting folder for your domain |

The Measurement ID is public. Passwords, login cookies, recovery codes and API secrets are private and must never be copied into your public site or tutorial.

## 1. Check what already exists

Open your website and source project. Identify the framework, version, page router, package manager, build command and hosting method. Search for existing Google Analytics, Tag Manager, `gtag`, `dataLayer`, `G-` and `GTM-` tags. Check for an existing visitor consent tool. Reuse or repair an existing installation instead of adding another tag.

GoDaddy sells several hosting products. A cPanel static-site deployment, WordPress and the Website Builder use different setup procedures. This worked method uses a Next.js static export, a separate WordPress blog/newsletter, and a PHP waitlist hosted in cPanel. For another product, use that product's supported integration and preserve its existing deployment procedure.

## 2. Create your property and Web stream

Sign into [Google Analytics](https://analytics.google.com/). Open Admin and create an account/property if you do not already have the correct one. Choose your own property name, country, reporting timezone and currency. Select the objectives appropriate to your website. Review optional account data-sharing settings yourself.

Review and accept the applicable terms yourself. When asked for a platform, choose **Web**. Enter your real website URL and a stream name such as **My Website**. Keep Enhanced Measurement on. Copy the newly generated `G-` Measurement ID. [Google's setup guide](https://support.google.com/analytics/answer/14183469).

Do not select Android or iOS just because you intend to read these reports on a phone. Those stream types measure activity inside native apps you develop.

## 3. Connect the site at its shared root

For Next.js, place the integration in the application's root layout or wrapper so all current and future pages inherit it. Use the framework's supported Google integration when its options meet your needs; otherwise use `next/script` for the standard Google tag. Keep one loader and one pageview owner. [Next.js Google integration](https://nextjs.org/docs/app/guides/third-party-libraries).

For a static export, a common configuration is:

```dotenv
# .env.production — replace this placeholder before building
NEXT_PUBLIC_GA_MEASUREMENT_ID=G-XXXXXXXXXX
```

Public environment variables are embedded during the build. Changing a value on your laptop or hosting account does not update JavaScript already deployed; rebuild and upload the new export. Do not upload your environment files themselves into the public web root.

Choose one navigation mechanism:

- Automatic: Google handles initial loads and Enhanced Measurement history changes. Do not also send manual pageviews.
- Explicit root tracking: set `send_page_view:false`, turn off Enhanced Measurement's browser-history pageviews, and send one clean pageview when the router commits a different pathname. This method needs regression tests for direct load, back/forward and reload.

The recorded implementation used explicit root tracking to exclude all query strings/fragments and set the correct page title and previous-page context. Its page context is global so interaction events inherit the current route. Google's queue must keep the documented `arguments` object format; replacing it with a rest array prevented collection in the observed browser test. [Google's pageview guidance](https://developers.google.com/analytics/devguides/collection/ga4/views).

### Cover separate applications and subdomains

Inventory every public application: `example.com`, `blog.example.com`, newsletter pages, signup and confirmation pages, and download pages. A root React component cannot automatically cover a separate WordPress or PHP application.

Use the same Measurement ID throughout. If you use a maintained WordPress Analytics integration, configure it once and avoid adding a second tag. The downloadable reference follows our custom approach: build a small shared analytics module, with a React adapter for Next.js and a DOM adapter for WordPress/PHP. Load the WordPress adapter once through a must-use plugin attached to `wp_footer`; call that same renderer from a standalone PHP template that does not use the theme footer. Future public pages then inherit the integration. Exclude administration, editor previews and feeds.

Share the analytics choice using a secure first-party cookie scoped to `.example.com`. In this method the choice lasts 180 days and can be changed through Analytics preferences. Keep Google ad-related consent denied. Test the real main-domain → subdomain journey; verify the choice carries across and pageviews remain single. Separate unrelated domains require Google's cross-domain configuration; do not assume a shared cookie will work there.

If an application has a Content Security Policy, preserve it and add only the tag/collection sources required by the observed integration. Check console errors and actual network traffic. [Google's CSP guide](https://developers.google.com/tag-platform/security/guides/csp).

## 4. Protect visitor information

Integrate with your existing consent system. The recorded method adds an optional analytics choice, loads no Google tag until the visitor allows it, and supplies an accessible preferences control to change that choice. Rejection stops collection. Advertising features are not needed for this website-traffic tutorial. Review the requirements applicable to your own site and audience. [Google's consent implementation guide](https://developers.google.com/tag-platform/security/guides/consent).

Use fixed event labels such as `preview_demo` or `contact_button`, not visitor-entered names, emails, passwords or messages. Never scrape form values or authentication details into analytics. Turn on email redaction and configure sensitive query-parameter redaction as additional safeguards. These safeguards do not replace avoiding personal data in the first place. [GA4 data redaction](https://support.google.com/analytics/answer/13544947).

Disable Enhanced Measurement site-search collection when search terms might contain private text. Save the settings, reload the Analytics page, and verify the switch remains off. Set a generic search-page title before initializing the tag.

If you remove all URL query strings, record that UTM campaign parameters are removed too. Do not promise campaign attribution that you have not implemented and tested.

## 5. Measure real interactions

Keep supported Enhanced Measurement interactions enabled, with the pageview and site-search exceptions described above: scrolls, outbound clicks, downloads, forms and supported YouTube embeds. Only claim to have tested interactions your site actually contains. [Enhanced Measurement](https://support.google.com/analytics/answer/9216061).

Use custom events only when they add meaning. For example, `cta_click` can identify a primary demo button. A contact-success event should fire only after the server accepts the submission. A newsletter link click is not a completed signup, and a server response does not prove delivery to a mailbox. Do not invent PDF, video or fundraising events for links that do not exist.

For Jetpack newsletter forms, use its server-side submission result hook. Only an accepted provider response may create a short-lived, non-personal result flag; consume it once on the redirected page to emit `newsletter_submit`. Never infer success from a visitor-controlled URL parameter. This means an accepted request, not a confirmed subscription or delivered email. Keep delivery/open statistics in the newsletter provider's reports.

For a separate waitlist, emit `waitlist_submit` only after the server accepts the request, and `waitlist_confirmed` only after the database reports the first successful confirmation. Reopening a confirmation link must not repeat that event. Send no names, email addresses, form contents, CSRF values or confirmation tokens.

## 6. Build and test before uploading

Run the project's dependency check, lint, typecheck, tests and production build. Serve the actual static export locally. Keep local test collection out of the real property by intercepting all observed collection endpoints in an isolated browser test. A synthetic HTTP 204 response avoids fallback retries; stop the test page before removing interception. Scope form-response stubs to the form endpoint so they do not swallow analytics requests.

Check all of these:

1. No tag or collection before consent and after rejection.
2. One tag after allowing analytics.
3. Home → another page → a third page → browser back → forward → reload gives exactly one pageview per navigation, with correct titles and paths.
4. A CTA and supported enhanced interaction send the expected event.
5. A failed contact response sends no success event; a successful test response sends one. Use a local stub so this test does not send email.
6. Synthetic private query, fragment and form markers do not appear in collection payloads.
7. Revoking consent stops collection and remains effective after reload.
8. The site and preferences work at desktop and phone widths.

A successful build proves only the build. It does not prove Google received production traffic.

## 7. Deploy through your existing GoDaddy process

For a cPanel-hosted static site: GoDaddy My Products → your hosting product → cPanel Admin → File Manager. Confirm the domain's actual document root. Do not assume an add-on domain uses the top-level `public_html` folder.

Back up the live files outside the public web root. Record a manifest and hashes for the changed files. Upload the required export contents and generated assets to the correct root. Preserve PHP handlers, redirects, security rules, media, DNS/mail settings, old hashed assets needed by cached pages and separate WordPress data. Do not replace a whole hosting account with your export. Keep exact rollback instructions.

For WordPress, back up both files and the database using the existing hosting backup tool. Deploy only the reviewed plugin/template changes; preserve uploads, posts, subscribers and database configuration. Keep the blog document root separate from the main static export.

## 8. Prove production collection

Open your live HTTPS site. Allow analytics for the controlled test. Visit several pages, scroll and click one relevant CTA. Check browser network requests or Tag Assistant for the correct Measurement ID and successful collection requests.

In Google Analytics select **My Website → Reports → Realtime**. Look for fresh pageviews and the interaction event from the test window. Record the time, routes, event names and what the UI actually shows. Newly created properties and standard reports may need processing time. If Realtime has not shown the data, leave this checkpoint unfinished rather than calling it a pass.

## 9. Verify Android and iPhone separately

Open the official Google Analytics app on each phone. Use the same Google account, select **My Website**, and open **Realtime**. While that screen is open, visit the live website from another browser/device and perform the test action. Confirm the activity appears on each phone and record Android and iPhone results separately.

Use Reports or Dashboard for pages/screens, events, traffic acquisition, country and device category. Exact report collections depend on your property configuration. Detailed reports can lag behind Realtime. [Reports in the mobile app](https://support.google.com/analytics/answer/9924671).

A VPN can change the approximate country reported for your visit. Tracking protection, DNS filtering and rejected consent can prevent the test visit from being counted.

## Optional: DNS filtering troubleshooting

If you use pfSense/pfBlockerNG and required Google domains resolve to a blocking address, check DNSBL reports. Add only the required blocked domains to the applicable allowlist, then apply/force-reload DNSBL and retest DNS and HTTPS. Common initial hosts are:

```text
analytics.google.com
www.googletagmanager.com
www.google-analytics.com
```

Inspect the actual collection host if a regional endpoint is blocked; do not disable the firewall or allow every port. Saving a list alone may not activate it. A DNS allowlist does not override browser blockers or every other firewall rule. YouTube playback allowlisting is a separate optional task.

## Finish with evidence

Save the framework discovery, changed-file manifest/diff, public Measurement-ID location, event definitions, quality results, deployment result, live network observations, GA4 Realtime observations, Android result, iPhone result, limitations and rollback procedure. Add timestamps. Report **VERIFIED PASS** only after all required observations are real; otherwise report **BLOCKED** and name the remaining step.

For your own tutorial, record the flow: create Web stream → install at root → build/deploy → open Realtime → generate a real visit → show the same property on Android and iPhone. Mask account emails, hosting details, identifiers and personal notifications before publishing. Use a fresh demonstration property or placeholders in public code examples. Write the final narration after the recorded evidence exists.

## What the recorded example shows

The finished edit includes real Android Google Analytics screen footage showing one active test user, five page views and six total events (five page views plus one scroll). These are the original recorded values, not audience-growth results. The iPhone procedure is illustrated; the owner confirmed access on both phones. Push notification delivery was not tested. Browser Realtime evidence and phone observations remain separate checkpoints.