Multiple Structures for Offers and Integrations

An Offer can have more than one structure. You do not need a separate offer, or a separate integration, for every form.

Why this exists

You often have several structures that are almost the same. Two products, two landing pages, and the only difference is a single field. Copying the whole structure, and then maintaining both copies with all their modifications, is slow and easy to get wrong.

For when a second structure is the right answer and when it is not, see Form structure.

How structures reach an integration

Structures are attached to the offer. Integrations are added to the offer through its pingtree. So an integration works with whatever structures its offer has, without being linked to them itself.

When you map fields in that integration, you see the fields from all of the offer’s structures, deduplicated by name. You map each one once and it works for every structure.

Matching is by name only

PalDock matches fields by system name.

A lead always arrives from exactly one structure. When the integration builds its request, it looks up a field by its system name and takes whatever value that lead carried. It never asks which structure the lead came from.

The field type plays no part in this. An integration does not see whether a field is text, a number or a dropdown, and cannot work with that information. It only sees the name and the value.

This also means two structures can define the same system name with different field types and the integration will not notice. It takes the value it finds. Whether that is a problem depends on what the advertiser does with it.

What you need to keep true

This works only while the names stay consistent. Two rules:

• The same meaning must have the same system name in every structure on the offer. If one calls it phone and another phone_number, the integration sees two different fields and one of them will always be empty.
• The same system name must always mean the same thing. If id is a customer number in one structure and a product code in another, the integration will send the wrong value and nothing will warn you.

Use global fields wherever you can. Their system names are managed centrally, which is exactly what this depends on. Use local or custom fields only for what genuinely differs.

When a field is missing from one structure

Structures on the same offer are rarely identical, so a mapped field will sometimes have no value. By default it is sent empty. The advertiser receives the key with nothing in it.

That is often not what you want, so decide what should happen before you go live:

• Leave the field out of the request entirely with do-not-send.
• Fill it with a default value using Modify.
• Send it empty, if the advertiser accepts that.

Example

Two landing pages sell the same insurance. Structure A asks for a company ID, Structure B does not. Everything else is identical.

Put both structures on the same offer and add the integration to its pingtree. Map the shared fields once. For the company ID, use Modify to decide what happens when it is empty. One offer, one integration, two forms, nothing duplicated.