# Property details

Exactly four values are saved from this screen: the property name, the attribution window, the reporting time zone, and a list of IP ranges that should never be collected. The last two have real consequences — one moves every number in every report, the other silently throws traffic away.

## Where it is, and what it holds

In **Admin**, under the **Property** group, open **Property details** — the direct link is `/admin?sel=property-details`. The screen has two sections, **Basics** and **Traffic filtering**. What you save applies to the **active property**, the one selected in the picker at the top of the console.

> Property details: name, attribution window, time zone and IP filtering. — [analytics.adpix.io/en/admin?sel=property-details](https://analytics.adpix.io/en/admin?sel=property-details)

Exactly four values are stored from here:

| Field | What it decides | When it takes effect |
| --- | --- | --- |
| Property name | the label you see in the picker, in reports and in emails | immediately |
| Attribution window | the window the property declares, in days | in the server-to-server contract |
| Time zone | the boundary of every range and every day, hour, week and month bucket | immediately, across all history |
| Excluded CIDRs | which IP ranges are never collected at all | within a minute, going forward only |

Anything else you might expect to find here lives elsewhere: the domain, the measurement ID, enhanced measurement and cross-domain settings all sit on the **data stream**, not on the property. That is **Admin → Data streams**, described in [Data streams](analytics/collect/data-streams).

## Property name

It is a label and nothing more. Renaming moves no data and invalidates no ID — the tag on your site works from the measurement ID, never from the name.

Where it shows up: the property picker at the top of the console, report headers, Trash, and any email AdPix sends about this property. If you run several properties, pick a name you can find in a list without thinking; "Main site" stops being useful at the third property.

## Attribution window

A number of days, defaulting to 365. Today it does two things:

- it is stored on the property and on the collector's copy of the configuration;
- it is returned in the server-to-server verify response, alongside the property name and time zone, so a backend that sends events knows which window the property declares.

What it does **not** do is change a report's range. Every report takes its range from the date picker at the top of the screen, and a session's channel is computed at read time. An order's attribution snapshot is frozen at the moment that order is recorded and is never rewritten afterwards. So moving this number up or down does not change yesterday's figures.

## Time zone — the setting that moves everything

This is the most consequential field on the screen.

Event time is stored in UTC, but every report you read is built in the **property's time zone**: the bounds of the range you picked, and every day, hour, week and month bucket in every chart and table. For a property on `Asia/Tehran` that means a day starts at midnight in Tehran, not at midnight UTC.

> **Changing the time zone moves every number**
>
> No event changes, but because days are re-cut, "yesterday", "last 30 days" and every bucket on every chart end up holding slightly different contents — including reports for months that are already closed. If you publish monthly figures, make this change at the start of a period rather than in the middle of one, and tell whoever tracks the numbers.

Two practical points:

- **Your browser's time zone plays no part.** A colleague in Tehran and a colleague in Berlin see exactly the same range for "yesterday". That is deliberate.
- **An empty or unloadable value falls back to UTC.** You get no error; days simply get cut somewhere else. So if your day boundary looks a few hours off, check this field first.

The picker offers a short fixed list, not every zone in the world. If the property's zone is not on that list the field looks empty — that is display only; as long as you do not pick an entry, the stored value survives **Save changes** untouched.

More on how the zone shapes ranges is in [Date ranges and comparison](analytics/reports/date-ranges-and-comparison).

## Traffic filtering — Excluded CIDRs

The screen's own hint says it: "One CIDR per line, e.g. 203.0.113.0/24. Matching requests are dropped before reporting." One range per line, in standard notation:

```text
203.0.113.0/24
198.51.100.7/32
```

Write a single address as `/32`. A line that is not a valid range is ignored without a warning, so re-open the screen after saving and read back what stuck.

> **This is not a report filter — the data is never created**
>
> A request whose sender IP falls in one of these ranges is dropped at the collector: no event is written, no session, no user. It cannot be undone — if you discover six months later that the range was wrong, those six months of traffic do not exist to be recovered. Check the range carefully; a `/16` where you meant a `/24` can silence a large share of your real customers.

Three behaviours worth knowing before you save:

- **It does not clean up the past.** The filter only applies to traffic that arrives after you save. Removing data already collected is a separate path.
- **It takes a few seconds to a minute.** The collector keeps this list in memory and refreshes it every minute, so a few more events may still land right after you save.
- **It does not filter server-to-server sends.** An event your backend posts with a server key does not go through this check; the filter is for browser traffic.

> **No fixed IP?**
>
> If your team works from home or on changing addresses, a CIDR list will not help. Set the `__sov_x` cookie to `1` in your own browser instead: the tag sends nothing, and the collector drops anything that does arrive with that cookie. The opt-out lives in that browser and affects nobody else.

## Phone numbers and the default calling code

When a visitor signs in with a mobile number, AdPix normalises the number to international form before hashing it, so that `0912…` and `+98912…` reach the same user. The rule is simple: a number starting with `+` is kept as it is; otherwise a leading zero is dropped and the default calling code is placed in front.

That default calling code is held on the **data stream**, not on this screen, and there is no field for it in the console today. If you collect numbers in national form and want them to merge with the international form, ask AdPix support to set it for your stream. Until it is set, the safest thing you can do is send numbers as `+98…` from your side; a server-to-server call may also carry the calling code in the request itself, which is used when the stream has no value of its own.

## Who can view and who can save

| Action | Minimum access |
| --- | --- |
| Open this screen | Viewer on the property |
| Save changes | Editor on the property |
| Delete or restore the property | Account admin |

If your role cannot edit, the screen still opens but carries this line at the top: "Read-only — your role can view but not edit these settings." — and the Cancel and Save changes buttons are not rendered at all. That is a role limit, not a plan limit; the difference is in [Plans and entitlements](analytics/admin/plans-and-entitlements).

## Every save is recorded

Each time you select Save changes, AdPix writes a row into the property's history: who, when, from which IP, and the before and after values of those fields. Deleting and restoring a property are recorded the same way. The rows show up under **Admin → Property change history** and are explained in [Change history and Trash](analytics/admin/change-history-and-trash).

If a number went strange from one specific day onward, read that history first — in most "the report broke" cases there is a time-zone change or a new IP range behind it.

## Frequently asked questions

### If I change the time zone, what happens to past reports?

Every number you read from then on is computed in the new zone, including reports for months that are already over. No data is rewritten; only the day boundary moves, so the same range you looked at yesterday can return a slightly different number today. If you publish a monthly report, make this change at the start of a period.

### My property's time zone is not in the list.

The picker on this screen offers a short fixed list, not every IANA zone. If the property's zone is not on it the field looks empty; the stored value stays exactly as it is until you pick something, so you can safely save the other fields. To move to a zone that is not listed, ask AdPix support.

### How do I keep our own office traffic out of the reports?

Put the office IP range in Excluded CIDRs. From the moment you save — in practice within a minute — nothing from that range is stored. It does not remove data already collected. If your team has no fixed IP, set the `__sov_x` cookie to `1` in your own browser instead.

### Does changing the attribution window rewrite my reports?

No. Unlike the time zone, this number does not change a report's range — the date picker does that. The attribution window is the window the property declares, and AdPix returns it in the server-to-server verify response so your backend can work to the same number.

## Related

- [Change history and Trash](https://docs.adpix.io/en/analytics/admin/change-history-and-trash/)
- [Date ranges and comparison](https://docs.adpix.io/en/analytics/reports/date-ranges-and-comparison/)
- [Data streams](https://docs.adpix.io/en/analytics/collect/data-streams/)
- [Plans and entitlements](https://docs.adpix.io/en/analytics/admin/plans-and-entitlements/)

---

[Docs](https://docs.adpix.io/en/analytics/admin/property-settings/) · AdPix