Targeting rules and placements

Targeting selects which offering a customer receives and which offering to use at an app placement. For example, customers of a particular app can receive a different upgrade offering without a separate app release for every audience.

This guide covers the dashboard. Your app must consume the selected offering; a rule cannot automatically replace a screen hard-coded to use another offering.

Before you start

• Create a project and app and connect the SDK.
• Prepare offerings and purchasable packages.
• Keep a valid project default offering for unmatched customers.
• Ensure you have targeting create/update permissions; review collaborator access.

Start with initial setup if needed. Targeting is optional for the first purchase.

Test the default purchase flow first, then add and test each rule independently. Changing products, offerings, and targeting at the same time makes diagnosis difficult.

Create a rule in the dashboard

1. Select the project and open Targeting in the sidebar.

2. Choose New rule and enter a recognizable name, such as “Upgrade offer for newer app versions”. The name is not a placement identifier.
3. Under If customer matches, choose the condition, operator, and value. App-version conditions also require an app; custom attributes require their attribute key.
4. Use Add condition to narrow the audience. All conditions in a rule must match.
5. Select the general offering. Use Add placement when different app locations need separate offerings.
6. Choose Running, Scheduled, or Inactive and review dates and timezone.
7. Save, locate the rule under its status tab, and test a matching and non-matching customer.

Available conditions

These are the current editor options. New-customer status, last-purchase dates, and returning behavior are not automatically available as standalone criteria without appropriate data and conditions.

Operators and condition logic

Country, app, platform, and custom attributes support membership (in) and exclusion (not in). App/SDK versions support greater-than, less-than, equals, not-equals, and greater-than-or-equal in the current editor. App version means your application version; SDK version means the InAppify library version.

Separate conditions use AND. Country Iran plus App A requires both. Within a membership condition, any selected value can match. For alternative complex paths, create separate rules and review priority; the editor is not an arbitrary nested AND/OR group builder.

Selecting Any audience, after confirmation, removes the other conditions in that rule. Do not keep multiple active any-audience rules in a project or combine this option with ordinary conditions.

Custom attributes and required data

Suppose your integration records segment = new_customer. Select Custom attribute → segment → in → new_customer. These are sample identifiers, not automatic InAppify keys; your app or server must actually record them.

Rules cannot infer missing attributes. In the V2 engine, missing country, version, or attribute data causes its condition not to match, including exclusion conditions. Do not use not in to detect missing attributes. Check actual targeting country data rather than inferring it from interface language or phone numbers.

A rule supports up to 25 conditions. Begin with small, testable rules.

What is a placement?

A placement is a stable name for an app location that requests or displays an offering, such as onboarding, upgrade, or settings. It is not a product, offering, customer, or rule.

Conditions determine which rule matches the customer; placements determine which offering from that rule to use at each location. The same customer may see an introductory offering during onboarding and a full subscription offering on the upgrade screen.

Create and use placements

1. Identify app locations and choose stable identifiers.
2. In the rule editor, choose Add placement, select an existing identifier or enter one, and assign an offering. New identifiers are recorded in the project when saving; no separate project-creation screen is needed.
3. For example, map onboarding to welcome_offer and upgrade to premium_offer. Replace these sample offering identifiers with actual project offerings.
4. In the app, use your SDK version's placement result to select and display the offering. The identifier must exactly match the dashboard; do not substitute the rule's display name. See SDK integration.

Identifiers accept English letters, digits, hyphens, and underscores, up to 100 characters. Do not use spaces or Persian characters. A rule supports up to 50 placement mappings without duplicate identifiers.

Other locations and empty results

Review For all other cases and, when shown, When not using placements alongside placement mappings. These configure the rule's general path, not the project default offering.

In the V2 engine, placements come from the first matching rule; later rules do not contribute additional mappings. A placement without an offering uses that rule's fallback when available, otherwise its result can be null. An undefined placement may be absent. Handle these states in your integration; an empty result does not automatically continue to another rule.

Scheduling and rule states

• Running: participates in offering selection, optionally with an end date.
• Scheduled: requires a start and end date/time for the campaign.
• Inactive: saved but excluded from selection; useful for preparation and review.

The list separates rules by these states. Inactive-rule actions offer Schedule. Depending on state, actions also include adding an end date, activating, deactivating, editing, and duplicating. Review saved dates and state after changes.

Scheduling controls rule participation; it does not send SMS, notifications, or make purchases, and does not necessarily refresh a screen already open in the app.

Scheduling precision

The current server checks scheduled starts and ends hourly. Do not promise activation at the exact selected minute. For time-sensitive campaigns, verify actual dashboard state and app results afterward.

Although the dashboard has a timezone selector, the current backend date-conversion/display path does not explicitly apply the selected timezone during conversion. For campaigns sensitive to Tehran versus UTC offsets, confirm the saved times with support rather than relying only on that selector. This describes current behavior, not a corrected scheduling guarantee.

How rule order affects targeting

Active rules are evaluated top to bottom; the first match wins. Later rules are not evaluated for that selection. A more specific condition does not automatically gain priority.

Example: “Any audience → General offering” appears above “App A → Special offering”. App A customers match the first rule and never reach the special one. Move the App A rule above the general rule to give those customers the special offering while others receive the general one.

Reorder rules

1. Open Targeting → Running.

2. Choose Change rules and drag rows into order. The current interface submits the order on drag release; it has no separate save button here.
3. Return and verify the saved order. Scheduled/inactive rules are not displayed in this active-rule reorder view; review their priority after activation too.

Place specific rules above general rules. Reordering can change the offering and placements received by overlapping audiences without changing conditions or products. It does not rewrite past purchases or purchased entitlements.

When no active rule matches, the project default offering supplies the general result. Keep it complete.

Testing and troubleshooting

• Check the project, app, active state, and priority.
• Ensure offering packages/products are usable by the test app.
• Test known matching/non-matching customers; avoid an any-audience rule above specific rules.
• Inspect actual attributes, country, app version, and SDK version.
• Check placement identifiers and empty-result handling.
• Refresh offerings in the app; cached results or an already-open screen may not reflect changes. Refresh behavior depends on SDK version; do not assume V1 and V2 behave identically.
• Retest after reordering or scheduled activation. Inspect matching rules above the expected one, not only the intended rule itself.

Use charts and reports alongside real customer tests. Targeting selects offerings; A/B experimentation is a separate concept.

Continue setup

After checking rules and placements, complete the production-readiness checklist. If you do not need targeting, go directly to that checklist after the test purchase.