Engagement Rx engages your members to help facilitate new membership on-boarding and facility usage. Engagement occurs as a result of data received from your membership system. This document covers two different methods of transmitting membership activity to Engagement Rx.
Batch Files
Batch files can be used to transfer member-related data to Engagement Rx. These files can either be transmitted to an Avidon Health hosted SFTP site or automatically retrieved from your own hosted SFTP or FTPS site. The FTP information will be collected and/or provided to you during the implementation process.
File Naming Convention
Engagement Rx can support any file name convention. The only requirement is that each file made available needs to have a unique filename. It is common practice to add the date the file was created as part of the filename. For example:
membershipactivity-2023-03-01.csv
General File Specifications
All files must use the standard CSV format following RFC 4180. The general file specifications are described in the table below:
| Status Code | Description |
| File Format | Comma-Separated Values (CSV) following RFC 4180 |
| Character Code | ASCII |
| File Header | A file header row is included as the first row of the file. |
| Field Delimiter | Comma , |
| Row Delimiter | Carriage Return + Line Feed (CRLF) |
| File Header | The first row of the file must contain the column header names described below |
New Memberships File
The purpose of the New Memberships file is to start an engagement campaign to facilitate on-boarding for your new members.
The New Memberships file should contain a list of all new memberships started since the last file was sent to Engagement Rx.
Import Rules
Engagement Rx uses the following business rules for processing New Memberships files:
- New users are added to the system.
- If a user already exists in Engagement Rx system, the user’s information is updated.
File Specifications
The file must contain all fields indicated as required below. Please see notes regarding some optional fields that while optional, are recommended to increase engagement and personalization for the member.
| Field Name | Required | Type | Notes |
| KeyField | Yes | String, Max 255 characters | The identifier which uniquely identifies an individual in your system. This is often a membership number |
| FirstName | Yes | String, Max 45 characters | The user’s first name |
| LastName | Yes | String, Max 45 characters | The user’s last name |
| Yes | String, Max 255 characters | The user’s email address | |
| SmsPhoneNumber | No 1 | E.164 formatted phone number | The user’s mobile phone number which can receive text messages |
| Birthdate | No 2 | ISO 8601 formatted date | |
| Gender | No 2 | String, (see notes for valid values) | Valid values include: “Male”, “Female", “TransMale”, “TransFemale”, “GenderQueer”, “NonBinary” |
| MessagingOptIn | No 2 | Boolean, true or false | Indicates if the member has opted into our out of communications |
| MembershipStartDate | Yes | ISO 8601 formatted date | The date the new membership started |
| MembershipExpirationDate | Yes | ISO 8601 formatted date | The date the membership expires |
| Segment | No 2 | String, (see notes for valid values) | Valid values include: “predisposed” or “notpredisposed” |
| PreviousMember | No 2 | Boolean, true or false | Indicates if a member previously had a membership |
1 Not required but preferred to increase engagement by allowing multi-channel communications.
2 Not required but preferred to increase the level of personalization provided by Engagement Rx
Membership Activity File
The purpose of the Membership Activity file is to inform Engagement Rx if your members are meeting minimum expectations regarding facility usage at 10, 21, 30, 60 and 90 days after membership has started. You can choose to use a single file or multiple files for transmitting information on your member activity, but all files should follow the same specification described below.
Import Rules
Engagement Rx uses the following business rules for processing Membership Activity files:
- A member record is located by KeyField
If the member is found- The provided event is recorded within Engagement Rx
- An engagement campaign is started according to the event recorded
- If the member is not found, no engagement campaign is started.
File Specifications
The file must contain all the fields listed below.
| Field Name | Required | Type | Notes |
| Keyfield | Yes | String, Max 255 characters | The identifier which uniquely identifies an individual in your system. This is often a membership number |
| EventCode | Yes | String, Max 255 characters | One of the Membership Activity Events as described in the Events section later in this document |
API
The Engagement Rx API can be used to transmit data to Engagement Rx in real-time. The below documentation describes the recommended process to follow and API methods to utilize to send new membership information and membership activity.
General API usage information can be found in the Engagement Rx API page on the Engagement Rx Documentation site.
New Membership
The following process should be used when using the Engagement Rx API for transmitting new membership information:
- Call API to: Get member by key field
- If not found, call API to: create a new member
- If found, call API to: update the member
- Call API to: record an event: CommunityMembershipStarted
Membership Activity
The following process should be used when using the Engagement Rx API for transmitting membership activity:
- Call API to: Get member by key field
- If not found, call API to: create a new member
- If found, call API to: update the member
- Call API to: Record an event using the applicable event listed in the Membership Activity Events section
API Methods
Below is a list of the relevant API methods to support the New Membership and Membership Activity processes described above. Detailed API method information can be found in the Engagement Rx API Reference documentation.
Get member by keyfield
Create a new member
Update the member
Record an event
Membership Activity Events
The table below describes the event codes to use to describe member activity and when they should be used.
| EventCode | When to use |
| Community10DayUsageTrue | If the member has used the facility at least 4 times in the last 10 days. |
| Community10DayUsageFalse | If the member has NOT used the facility at least 4 times in the last 10 days. |
| Community21DayUsageTrue | If the member has used the facility at least 4 times in the last 21 days. |
| Community21DayUsageFalse | If the member has NOT used the facility at least 4 times in the last 21 days. |
| Community30DayUsageTrue | If the member has used the facility at least 4 times in the last 30 days. |
| Community30DayUsageFalse | If the member has NOT used the facility at least 4 times in the last 30 days. |
| Community60DayUsageTrue | If the member has used the facility at least 4 times in the last 60 days. |
| Community60DayUsageFalse | If the member has NOT used the facility at least 4 times in the last 60 days. |
| Community90DayUsageTrue | If the member has used the facility at least 4 times in the last 90 days. |
| Community90DayUsageFalse | If the member has NOT used the facility at least 4 times in the last 90 days. |
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article