Image Modified

Tier expiration mechanism enhancements

Two new tier expiration settings have been introduced for tier structures configured in the Tiers module.

Image Modified

• Cross tier membership refund handling (available calendar expiration logic)
  If the checkbox is enabled and the checkout was made before the last calendar expiration date, tier points are not deducted and downgrading does not occur upon refund.

Image Modified

This way the refund of transactions made in previous periods will not affect the customer’s current tier status and progress in the tier structure.

Reset tier points on the expiration while keeping the highest tier in the next period (available for calendar and anniversary expiration logics)
The new Destination tier setting prevents customers from being downgraded from the highest tier they have reached in the previous expiration period based on the number of tier points collected. However, the tier points are reset to 0 on the expiration day, which means that customers have to earn their way from the bottom to achieve an even higher tier than what they reached in the previous period.
The new option does not allow setting grace periods:
❌ No Tier grace period, as the highest tier that customers achieved in the previous period is always kept until the next expiration date.
❌ No Tier points grace period, as tier points are reset on the expiration date regardless of when they were earned.

Image Modified

Using this logic, the frustration that expiration causes for customers can be reduced by giving them enough time to enjoy benefits, while still keeping them mindful of expiration dates.

Compatibility improvement

• The compatibility of the Multi-accounts module has been extended to the Offline treasure hunt module.
  The ‘Account’ field is now available on the configuration pages of offline treasure hunts. The events related to treasure hunt participation (Offline treasure found, Offline treasure code found) will be registered under the associated account in the customers' event histories.

Image Modified

Coupon-related feature enhancements

• A coupon’s claimed status indicates that the coupon has been assigned to a loyalty member. However, the member might lose the eligibility to use the coupon (eg. due to segment restrictions or fraudulent behavior)) and it is necessary to withdraw the coupon from its assignee.
  Previously, the only way to unassign the coupon (removing the tie between the coupon itself and the loyalty member) was to invalidate the coupon. With the introduction of the coupon_unassign event, it is now possible to unassign the coupon without invalidating it. This event changes the status of the coupon from claimed to unassigned which means that the coupon is available for future reassignment to another customer, therefore the system will not be loaded with invalid coupons.
  This event can beregistered through the Events API or manually in the Backoffice.

Image Modified

The unassign_coupon event is compatible with the Pending events module which can provide a time window for a review before the coupon is disconnected from its assignee.

Events API endpoint to send the POST request to: /events
Payload to add:

{
  "customer": "{customer_id}",
  "action": "coupon_unassign",
  "data": {
    "code": "{coupon_code}"
  }
}

• The number of coupons issued to customers from bulk-generated coupon pools has been maximized to 1% of the unique combinations of the configured coupon pattern. This prevents the possibility that customers (who might be familiar with the pattern already) make lucky guesses on valid coupon codes.
  To ensure that 1% of the combinations is able to serve high demands, at least 4 variables have to be added to the coupon pattern.
  The dynamically calculated disclaimer inserted into the interface gives clarity on the limitations and restrictions.

Image Modified

When more than 5 million coupons are distributed, the number of coupons generated in one batch has been restricted to maximum of 5 million coupons, to ensure each batch is generated without delays.

Image Modified

Braze integration

Antavo is introducing its integration with Braze customer engagement platform. The integration provides the following benefits:

• Enables loyalty member data synchronization from Antavo to Braze.
  This allows businesses to have the loyalty data (eg. point balances and tier membership status) seamlessly transferred to Braze where it can be used for segmentation and personalization of communications.

Image Modified

• Antavo events can be synchronized to Braze with payload through the new Sync Braze events workflow action node in the Workflows module.
  This allows businesses to build communication journeys in Braze based on loyalty events triggered or processed in Antavo.

Image Modified

Platform usability improvements

• The currently used search filters on Backoffice interfaces are being replaced by single-line auto-fill filters that apply logical operators to find items more easily.
  With this release, the new filter will be introduced on the following pages:

  • Security log

  • Incoming webhooks log

  • Banned users

  • Transactions page

  • Maitre’D log

Image Modified

• The configuration interface of the Event trigger workflow node has been extended with the option to enter multiple events with the aim to save the time that users spend with configuration.
  The new multi-select field allows to have multiple events that may trigger the execution of a workflow, so there’s no need to configure a workflow for each triggering event.

Image Modified

The Event column has also been added to the log pages of workflows for traceability.

Changes in the status of modules

• Starting with this release, the Trusted sites and the Webhooks (beta) module will become the officially supported and recommended way to configure outbound communications from Antavo.
  With this change, the

  Status
  colour Yellow title EARLY ACCESS

  tag will be removed from these modules in the Module list.
  The mentioned modules replace the previous Webhooks module which is now tagged with

  Status
  colour Red title LEGACY

  status, suggesting that this module is still operational, but it is outdated.
  The new modules provide the interface to configure and manage multiple webhook authentication methods on one single page, there’s no need to configure the same endpoint every time it is used in a workflow.
  In case you use the old module, please contact the Antavo Service Desk to consult about switching to the supported modules.

Contest lite module improvements

The recent updates to the Contest Lite module's page aim to provide convenient access to key functionalities of the module. Here's what has changed:

• Each contest on the module's opening page now has a hamburger menu. Within this menu, the following options are available:

  • Edit – This button redirects the platform user to the editing page where contest details can be modified as needed.

  • Winner Selection – The action button for selecting winners of a contest after it has ended.

  • Copy ID – This new button copies the ID of the contest to the clipboard, which serves to conveniently paste the ID when configuring contest-related workflows in the Workflows module.

• Contest status – The status of each contest is now displayed below their name. This makes it easier to check if a contest is active, inactive, completed, or scheduled.

• It is now possible to archive inactive and completed contests in the system.

Image Modified

• Rewarding customers with multiple contest entries within one single promotion_enter event is configurable in the Workflow editor through the Participate in contest workflow node.
  With this release, the count property is also available to set the number of contest entries to assign when entering the customer through the Display API as well. This way there’s no need to send multiple requests to register each entry, which helps businesses to save network bandwidth and build campaigns including contest entries at scale.

  Display API endpoint to send the POST request to: /customers/{customer_id}/activities/contests/{contest_id}/enter
  Payload to add:

{
    "count": {number_of_entries}
}

• With our 2023-06-13 release, the contest_entry_revoke event was introduced to delete customers' entries to contests configures in the Contest lite module.
  After the current release, it is the newly introduced refund_contest_entry event that gives back the points to the customer point balance instead of the contest_entry_revoke event. The new event is automatically written down if the refund_points boolean attribute of the previously introduced contest_entry_revoke event is registered with true value.
  This change makes it possible to use the new refund_contest_entry event as an event trigger in workflows to set up automated mechanisms (eg. adding the customers to a list or notifying them about refunded points via email).

Multilanguage support

• So far, names of questions under the Gamified profiling module could be translated to languages added previously in the Multilanguage module.
  Now the ‘Translate’ button is available to translate the text values of the possible answers as well.

Image Modified

In case the Accept-Language header is added to the request sent to the Display API endpoint, the response will include the translated values. There’s no need to translate the texts in the website environment when displaying the answers, the values can be inserted from the response.

Display API endpoint to send the GET request to: /customers/{customer_id}/activities/{flow_id}/next
Header: Accept-Language={language_id}
Response provided:

{
  "data": {
      "type": "like",
      "title": "{translated_title}",
      "description": "{translated_description}",
      "multi-choice": false,
      "position": 2,
      "answers": [
        {
          "id": "649ae9ab5118f301d459bc65",
          "text": "{translated_answer}",
          "tags": [],
          "image": {
            "small": "{image_URL}",
            "medium": "{image_URL}",
            "large": "{image_URL}",
          }
        }
      ],
      "_actions": {
        "answer": {
          "method": "POST",
          "url": "{endpoint_URL)"
        }
      }
    }
  }

Contest lite module developments

• The opening page of the Contest lite module now presents a list of contests sorted primarily by start date. The next criterion is the end date; followed by an alphabetical listing by name. This sorting mechanism facilitates efficient navigation, and the chronological order allows users to conveniently track the progress of ongoing contests.

• Participants of segment-restricted contests can now be excluded from the winner selection process if they are not part of the segment by the time of winner selection.

Integration update

• The deferred web request (JSON payload) processing mechanism that was introduced with the previous release package, has been extended to Shopify webhook requests sent to the orders/fulfilled, orders/cancel, and orders/delete endpoints.

Feasibility updates

• When updating brand settings in the Backoffice, validation is performed on a per-setting basis: only the modified brand properties are updated and validated when a setting is saved, ensuring that the current updates can be successfully saved.

• To avoid misunderstandings and inconsistent usage of accounts, Backoffice users are prevented from setting the account name as 'Default' in the Multi-accounts module. Saving an account name as 'Default' will trigger an error message.

• Private image handling option has been added to the platform. If the accessibility of images is set to private, the Display API endpoints return pre-signed URLs of media items uploaded to the Backoffice.
  Please contact the Antavo Service Desk if you want to get started with private image handling.

Integration updates

• Asynchronous web request (JSON payload) processing mechanism has been introduced for Shopify webhook requests sent to the orders/create and orders/updated endpoints. This ensures that Antavo responds instantly, and all the incoming requests in the queue get processed properly.

• New properties have been added to checkout, checkout_update, checkout_accept events to improve Antavo's Shopify integration. They can also be used outside of the Shopify integration.

• A new ‘Deferred sync’ checkbox on the Bloomreach settings page offers the solution to send customer update calls asynchronously.

• Resend mechanism has been introduced in the Webhook (beta) module. If a message fails, it is lined up in the queue and can get resent a maximum of five times if necessary.
  From now on, we advise using the Webhooks (beta) module as the primary webhook service (instead of the one called Webhooks). With the inclusion of the resend mechanism, this feature has now all capabilities that the original module has had, in addition, it simplifies the process of using webhooks by allowing you to pre-configure trusted sites, making it easier to manage and authorize webhook notifications to specific endpoints.

  To learn more about the advantages of Trusted sites and the utilization of the new Webhook message (beta) workflow node, please refer to the linked user manual resources.

Guest checkout handling

• When a guest checkout is claimed by a newly registered loyalty member, the points are allocated based on the checkout status.
  If the checkout is in a pending status based on the settings configured under the Checkout accept module, the points are added as pending points to the customer’s account and will be confirmed when the checkout_accept event is registered. If the checkout has already been accepted, the points are added as spendable points right away.
  The expiration date of the points is calculated based on the date of the checkout_accept event.

Contest lite module developments

• The Entity lookup workflow node now has the option to look for a contest based on the ID of the contest.

• Contests are now available through the Entities API.

• Anchor
  revoke-entry revoke-entry

  The contest revoke functionality has been introduced. The new contest_entry_revoke event can be used to remove customers' entries from contests if they are not eligible to participate in the contest anymore (eg. due to segment restrictions or fraudulent behavior). There’s an option to trigger this event through the Revoke from contest action node, by sending a request to the Events API or to the /revoke Display API endpoint provided by the Contest lite module.
  It is the refund_points boolean attribute of the contest_entry_revoke event, that controls if the points that the customer may have spent to enter the contest should be refunded to the customer’s point balance or not.

Tier mechanism enhancements

• A grace period for tiers and tier points/spend amount can now be configured under Tier structure configuration within the Tiers module.

  • The tier grace period ensures that no tier expiration will occur if a customer has been upgraded to a higher tier within a predefined time period from the expiration date.

  • The grace period applied on the point/spend amount carries the amount over to the next cycle if it has been collected within a predefined time period from the expiration date.

• A new tier expiration method is available that downgrades the customer maximum 1 tier in the tier structure if the threshold of the current tier is not met.

• If the tier point value of a point-based tier is reduced on the customer’s account, the number of tier points will be cut down points to maximum 0, even if the point deduction event would take away more than the customer’s current tier points value.

• The points_after_expiration customer property has been introduced that stores the number of tier points customers would have after the next tier expiration date.

  This new property is applicable in workflows, exports, and all customer filter options across the Backoffice. It is also accessible through the Customer API.

• The Tier recalculation workflow node is no longer available.

Coupon pattern update

• Uppercase alphabetic and alphanumeric characters can now be added to coupon patterns under Coupon pool settings.

Compatibility improvements

• The compatibility of the Multi-accounts module has been extended to the Challenges and the Friend referral modules.
  The account attribute can now be selected as a criterion under the ‘Filters’ section of the challenge editor, therefore only events with the attribute value of the selected account are counted into the challenge completion progress.
  The ‘Account’ field on the Friend referral module configuration interface is available to select to which account the referral points should be allocated via the referral_points and referral_bonus events.

• Spend-based tiers can now be associated with accounts. Only the spend amount of the account that is selected under the ‘Account’ field affects the customer’s tier status.

• The parallel use of the Pending events and Checkout accept modules is syntonized. To prevent inconsistencies, checkout-related events are not available under the Pending events module if the Checkout accept module is turned on.

• The card settings under the Friend referral configuration interface have been extended with ‘Translate’ buttons, so that translations of the card title and description texts can be added to each of the applicable languages.

• The following events have been added to the list of events that can be handled as pending events through the Pending events module: partial_refund, reward_transfer, release_points, refund_item, refund, and referral.

Addition to the release

• The Checkout accept module offers the option to automatically recalculate the auto accept or reject date of transactions when the transaction is updated by a checkout_update event.
  In case the Points economy or the Multi-accounts module is enabled, this setting is available under the Pending points tab of the configuration interface of these modules.

Loyalty feature enhancements

• The Tiered Campaigns feature has been updated to support two trigger types: event-type and transaction-type. The new, transaction-based trigger handles all events that have a transaction ID, while any other events can be activated using the event-type trigger.

  • Some of the event trigger types have been removed, such as checkout and checkout_item.

• Pending points (coming from pending checkouts) are now registered for Tiered campaign participants. This update also ensures that checkout_update and checkout_reject events modify the pending points from the tiered campaign. Tiered campaign bonus points will remain pending until evaluation. These points will not be awarded to the customer, if the acceptance does not happen before the campaign period ends.

• Challenges can now be exported. This enhancement is convenient when migrating content between environments or creating a large number of challenges. Kindly note that exporting this data model is only possible in JSON format, and CSV is not available.

Enhancements to scheduling options

There have been multiple improvements that affect scheduling settings in the Backoffice.

• The node that triggers workflows based on a specific date, known as ‘On a date’ can now execute the flows annually, in addition to daily, weekly, and monthly triggers.

• When putting the letter 'L' in a service automation (cron) job setting’s ‘Day of month’ field, the last day of the month will be considered as the execution date.

  This scheduling option is also available when configuring imports, exports and ‘On a date’-triggered workflows.

• The configuration of imports, exports, and workflows (including both campaigns and ‘On a date’-triggered general workflows) now reflects the actual execution and is now based on the UTC timezone and displayed in the Backoffice accordingly.

  This is important to guarantee consistent timing of these processes, preventing discrepancies due to different timezones, international date line crossings, or differences for countries applying daylight saving time.

Earn rules

• Segment-specific earn rules can be configured in the Incentivized purchase module and the Earn rules tab Multi-accounts modules. Each of these special rules can be further specified with currency-based calculations.

• The calculator that appears on the interface of both modules has also been redesigned to provide a clear understanding of the calculation method that is applied based on the configured segment and currency-specific settings as well.

Interface enhancements

• New labels have been introduced on the Event history page of the customer profile that indicates the status of the points earned through registered events.

  • Status
    title EXHAUSTED

    - points have been spent already

  • Status
    title EXPIRED

    - points have expired

  • Status
    title EXPIRING

    - points are about to expire the next time the scheduled expiration service runs

• The accessibility of certain modules is displayed on the Modules list with newly inserted tags.
  

  Status
  colour Blue title UNDER DEVELOPMENT

  Status
  colour Yellow title EARLY ACCESS

  Status
  title DEPRECATED

  Status
  colour Red title LEGACY

Compatibility improvements

• The following events have been added to the list of events that can be handled as pending events through the Pending events module: checkout, checkout_item, checkout_claim, coupon, coupon_unredeem, coupon_redeem, coupon_transfer, coupon_invalidate, coupon_create, share, share_impression, and reward_revoke.

• The compatibility of the Multi-accounts module has been extended to the Instagram contests module. The ‘Account’ field is now available on the configuration pages of Instagram contests. The events related to contest participation (contest_enter, winner, non_winner) will be registered under the associated account.

Multi-accounts

• The compatibility of the Multi-accounts module has been further extended, the ‘Account’ field is now available on the Quizzes and Gamified profiling module configuration pages as well.
  The points that customers earn when completing quizzes and profiling question flows will be added to the selected account.
  The related events must have the same account property value as of the configured quiz or question flow.

• When configuring new entities, assigning an account is now a mandatory setting throughout the Backoffice editor interfaces. The default account is pre-selected in the ‘Account’ fields, you can use the dropdown list to assign another account.

• A warning message is displayed on the screen if there’s no default account selected in the Multi-accounts setting.
  To facilitate the configuration of the default account, the first account created in the Multi-account module is selected as the default account automatically upon activation.

Point handling

• A new type of point expiration logic has been introduced in the Expiring points module. Using the ‘Anniversary’ option, the point expiration date occurs annually, on the date stored in any (required) date or datetime type of customer attribute of each customer.

• Two options were added to the Expiring points module to control when points reassigned to the customer through refunds should expire. Points can either keep the original expiration date or have a new expiration date calculated based on the current expiration settings.

• The ‘Earn rules’ interface of the Multi-accounts and Incentivized purchase modules has been extended with the option to define multiple currency-based point calculations in addition to the default percentage value.

Tiers

• A new, optional field has been added to the Tiers module, which allows the definition of actions that decrease tier points and may trigger a tier_down event consequently.
  This field can be found in the Point-based tier’s structure editor, right below the field that defines actions for tiering up.

Jobs

• The Jobs tab has been introduced under the Settings menu where cron jobs can be created and managed. The Log subpage of each configured job shows the history of cron jobs processes. The access to actions and logs related to jobs can be restricted to specific user roles under the Roles tab.

Checkout accept

• The auto-accept date of transactions can now be updated through the checkout and checkout_update events. The auto-accept date value of these events is copied to the transaction that has the same ID as specified in the transaction ID field of the checkout or checkout_update event.

Webhooks

• The new Webhooks (beta) module now allows the handling of dynamic URLs. Among the settings of its workflow node, there is a new field where additional parameters can be added to the end of the given site’s URL.

• Also, the Webhooks (beta) module page has now a ‘Queue’ submenu where Backoffice users can monitor the status of the webhook requests in case of asynchronous processing.

Platform interface enhancements

• The user interface of the Backoffice is changed by adding a > icon at the end of each menu row so that the menu item can expand. This way, Backoffice users can see more clearly what are the main menus and submenus.

• The Security logs page now lists 'Onboarding' as a new event type. This addition distinguishes regular logins and those when a newly created Backoffice user logs in for the first time.

• On the customer Events history page, the Transaction ID value of the checkout and checkout_update events has been serving as a link to the Transaction details page. With the last release, hyperlinks were added to the refund, refund_item, partial_refund and point_unburn events as well.

• The configuration page of the Burn rules module is updated. The redesigned interface provides a clear understanding of the calculation method that is applied based on the configured settings.
  This update was added to the Burn rules tab integrated into the Multi-accounts module as well.

API enhancement

• Pagination has been added to the /customers endpoint. Long responses can be broken up into small components.

Loyalty feature enhancements

• Tier expiration setup options are now extended with a new checkbox called ‘Downgrade’.

  If a customer's events would lead to a tier downgrade, the loyalty administrator can either downgrade the customer or by leaving the box unchecked, protect the customer from being downgraded until the next tier expiration date, irrespective of the events or point balance changes.

• Generating bulk coupons is now available. By defining the desired number of coupons in the Backoffice -ranging from 1 and 100 million-, the coupon codes will be generated and exportable right away.

• Customer labels are now introduced. Labels are descriptive tags that can be attached to customers, representing various characteristics such as user preferences, or any assignment that was appended from integrated CDPs. They appear in the 'Labels' field under the customer's profile in the Backoffice; as well as being listed under a new menu item in the Customer Insights module.

• The execution of customer mapping rules has been optimized to make sure updates are properly handled. Customer updates trigger the rules to run for the affected customers, and configuration updates of mapping rules trigger the rule to run for the whole customer base.

Webhooks (beta)

• The new ‘Webhook message (Beta)’ workflow action node has now been enhanced to send async requests to a third-party website.

Multi-accounts

• The compatibility of the Multi-accounts module is being extended.
  A new ‘Account’ field has been added to the configuration interfaces of the Prize wheels and the Contest lite modules. The points that customers spend to enter prize wheel- and contest-type promotions will be deducted from the selected account.

• Release and checkout events must have the same account property value as of the preliminary reserve event.
  Campaign_bonus_revoke events must have the same account property value as of the preliminary campaign_bonus event.
  If the account value of mentioned events is different, the events will be rejected and if empty, the account property will be automatically populated with the account value of the preliminary event.

• A new configuration option has been added to the Multi-accounts module that forces the incoming API request related to a point-burning entity - reward, prize wheel, contest - to have the same account value as the configured 'Account' field value of the entity.
  If an entity is added in the new multi-select force match field and the account value of a related request is different, the events will be rejected and if empty, the account property will be automatically populated with the account value of the configured entity.

Refund transactions

• The refund_amount action is now deprecated.

• The refund_item event now restores any associated points burned in the transaction relating to the refunded item.

Campaigns, workflows

• The Tiered campaigns editor is now available in the Backoffice. This module encourages customers to perform repeated actions by rewarding them based on the level achieved during a predefined amount of time. The configuration of Tiered campaigns comes with a wide range of custom triggers for events and transactions, product-specific settings and a grace period after the campaign ends.

• The Aggregated customer attribute workflow node has been introduced to assist the identification of misusage or abuse of the loyalty scheme so that preventive actions can be taken in time (eg. canceling the registration of an event, sending a notification to the customer about the terms of use).

• The Entity lookup workflow node has been extended with a new option that enables the transportation of the attributes of a pending event through a workflow.

• There is a new module called Webhooks (beta). This comes with a new Webhook message (beta) workflow node that shows a dropdown from which you can pick previously saved trusted sites.
  Compared to the Webhook message node that requires typing in the details of the authentication, the new node makes sending workflow-generated webhooks quicker and easier.

Multi-accounts

• Validation and cross-check mechanisms have been implemented to ensure the compatibility of the Multi-accounts module with the Checkout accept module and the refund procedure. The newly introduced mechanisms provide a smooth transition between the stages of the transaction lifecycle.

• The default account configuration is now a mandatory setting of the Multi-account module. If the account property of an event is empty, the default account is automatically assigned, or events that have a Transaction ID inherit the account of the checkout event with the same Transaction ID.
  Events sent with the same Transaction ID of the checkout event but with different account property, the event will be rejected due to mismatch.

• Reward_revoke and reward_unbid events must have the same account property value as the preliminary reward and reward_bid events, respectively.
  If the account value is different, the revoke and unbid events will be rejected and if empty, the account property will be automatically populated with the account of the preliminary event.

Platform change

• A default value is available for Custom entities and Custom events. When creating or editing a custom field, there is a Default value opportunity for the following field types: string, numeric, boolean and URL.

API changes

• /customers/-/eventsis a new endpoint like the customer events endpoint that returns all events in the platform with their associated customer_id.

• It is now possible to query customers using the updated_at field at the /customers endpoint.

• Offers can now be accessed via the Entities API. An example response has been provided here.

• New navigation options have been introduced in the Workflows module. The Log and Running workflows pages are directly available from the workflow list, and clicking the name of the workflows opens up the workflow editor.

• A new unit_burn attribute has been added to the Events and Transactions collections. This makes it possible to store burned points on an individual product level instead of storing them for multiple items at the checkout.

• There is a new ‘Email Settings’ tab under the brand's Settings page.
  This enables choosing the transport type from which the platform-generated emails are sent out to Backoffice users. Besides the default setting, there are two extra options: Simple Mail Transfer Protocol (SMTP) and Amazon Web Services' Simple Email Service (AWS-SES).

• When opening previously executed exports, their description now shows the object name instead of the objectID.