> For the complete documentation index, see [llms.txt](https://docs.adpage.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.adpage.io/app-tracking/server-container-basics.md).

# Server container basics

The GA4 App client, the naming convention, and the trigger rule that keeps app and web traffic apart.

This page covers what you set up once, before touching any platform.

## 1. Add the GA4 App client

In the server container, add a client of type **Google Analytics: GA4 (App)**. Give it a name you will recognise in triggers and in preview, for example `App tracking`. Leave the existing GA4 web client in place, it keeps serving the website.

Without this client, Firebase requests reach the container but no tag ever fires.

## 2. Use one naming convention

Name everything that handles app traffic with the same prefix, so a container stays readable when both sources run side by side:

| Object  | Pattern                      | Example               |
| ------- | ---------------------------- | --------------------- |
| Client  | `App tracking`               | `App tracking`        |
| Trigger | `App - <event>`              | `App - signup`        |
| Tag     | `<Platform> - App - <event>` | `Meta - App - signup` |

## 3. Build every app trigger on the client

An app trigger has two conditions:

* `Client Name` equals the App client, and
* `Event Name` equals the event you want.

Use a Custom trigger with both conditions rather than a Custom Event trigger on the event name alone.

{% hint style="info" %}
While you are here, check the triggers that already exist. Any trigger that fires on an event name without a `Client Name` condition will now also catch app traffic. Either add the condition, or give the app its own tag and let the web tag exclude the App client.
{% endhint %}

## 4. Add one tag per platform

| Platform   | What you add                                     | Notes                                                   |
| ---------- | ------------------------------------------------ | ------------------------------------------------------- |
| GA4        | A second GA4 tag, triggered on the App client    | Events land in the app data stream                      |
| Meta Ads   | A Meta tag with action source `app` and app data | Device information is mandatory                         |
| TikTok Ads | A TikTok tag with the app event source           | The app must exist on the TikTok side                   |
| Google Ads | Usually nothing                                  | App conversions run through the GA4 link, see that page |

## 5. Publish, then verify

Publish the container before asking anyone to test. A tag that sits unpublished in a workspace produces exactly the same symptom as a tag that does not exist, and the client tests against the live container.

After publishing, verify in the container's outgoing requests rather than relying on someone else's preview session. See **Testing and verification**.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.adpage.io/app-tracking/server-container-basics.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
