​
Member Bases

A memberbase is a named collection of members that acts as the primary audience container in Publisher. Every member belongs to exactly one memberbase, and all ad delivery, targeting, and reporting is scoped to a memberbase. You can think of a memberbase as a distinct audience pool — for example, a loyalty programme’s customer list or a publication’s subscriber base. Memberbases are created via the API and are identified by a unique ID assigned at creation time. Each memberbase can have its own attribute schema that defines what metadata fields are available on members within that base. This schema is used for targeting rules when configuring delivery — for example, you might define a tier attribute and then target ad placements only to members whose tier is “gold”.

​
When to Use Multiple Member Bases

Use separate memberbases to isolate distinct populations:
  • Different brands or products within your organisation
  • Separate environments (staging vs production)
  • Distinct loyalty programs with different member sets
Members, schemas, and configurations do not leak between memberbases. This isolation makes memberbases suitable for representing distinct audience segments, tenants, or programs within your organisation.

​
Lifecycle

  1. Create a memberbase to establish a new container.
  2. Add members to the base via the bulk upsert endpoint.
  3. Query the base to list or retrieve individual members.
  4. Delete when the base is no longer needed (removes all associated members).

​
Identifiers

Each memberbase has a system-generated id used in all subsequent API calls. You cannot rename or merge memberbases after creation. Operationally, memberbases are lightweight containers. They do not impose limits on the number of members they can hold, and you can create as many memberbases as your use case requires. Listing, filtering, and pagination of memberbases is supported through the standard list endpoint pattern used throughout the API.