Avo Functions in ReasonML

6 minute read

Platforms

Avo can code generate Avo Functions in ReasonML targeted at the following platforms

  • Web
  • React Native
  • Node.js

Quickstart

Avo functions usage consists of 4 steps.

Step 1. Include the Avo file

Pull the generated code with the Avo CLI

To get the Avo generated ReasonML file you must be a member of an Avo workspace with a ReasonML source. Ask for an invite from a colleague or create a new workspace

Terminal
Copy
$
$
$
npm install -g avo
avo login
avo pull --branch my-branch-name

Learn more about the CLI here.

You can also download the file manually from your Avo workspace.

Step 2. Initialize Avo

Import Avo from the generated file and initialize it by calling the initAvo method before tracking

reasonml
Copy
1
2
3
4
5
6
7
Avo.initAvo(
~env=`dev,
~systemProperties=Avo.AvoSystemProperties.t(),
[~destinationOptions=?],
[~customDestination=?],
()
);

The actual parameters depend on your tracking plan setup, see the parameters explanation in the reference below.

Step 3. Call Avo functions to track your product usage

Every event in your tracking plan, marked with the "Implement with Avo" checkbox, gets a function in the generated code, named according to the event name, in camelCase.

For example, if you have a "Signup Start" event defined like this in Avo:

Event 'Signup Start' defined in Avo with referral string property and implement with Avo check

You'll be able to call it like this from the generated code

reasonml
Copy
1
Avo.signupStart(~referral="direct");

Notice, that you are not passing the System property with the call. System properties are defined on the init step and then automatically included with all events. You can update the system properties with setSystemProperties function.

Step 4. Verify the implementation

Use the Implementation status in your Avo workspace and the visual debuggers to verify that your implementation is correct.

Reference

initAvo

reasonml
Copy
1
2
3
4
5
6
7
8
9
10
Avo.initAvo(
~env: AvoEnv,
~systemProperties: AvoSystemProperties.t,
~webDebugger: bool=true,
~noop: bool=false,
[~mobileDebugger: option(mobileDebuggerInstance)=?],
[~destinationOptions: option(DestinationOptions.t())=?],
[~customDestination: avoCustomDestination],
(): unit,
)

Initializes Avo, needs to be called before the tracking methods. This method will initialize the SDKs for all destinations that are managed by Avo, and call the make(env) callback in the provided custom destinations.

Arguments
  • env: AvoEnv, can be set to dev, prod and staging.
  • systemProperties: AvoSystemProperties.t, where each field represents a system property in your tracking plan. When you define system properties in your Avo workspace you set name and type - the fields of this object are named the same as system properties, in camelCase, and you should provide corresponding types, can be string, int, long, float, bool and list.
  • webDebugger: optional bool, for optional Avo Web Debugger instance
  • [noop=false]: optional bool, if set, Avo won't make any network calls (no tracking) in development and staging environments. Note that the noop flag is ignored in production.
  • [mobileDebugger]: React Native specific and optional Avo Debugger instance. Pass it to make the Avo functions automatically show the functions calls and all the errors in the visual debugger. Check React Native mobile debugger repo to learn more about it.

destinationOptions: [~segmentDestinationName=?], [~anotherSegmentDestinationName=?], [~amplitudeDestinationName=?], [~mixpanelDestinationName=?]. Keys of this object are the camelCase versions of your destinations in the Avo UI.

  • mixpanelDestinationName: optional Js.t, if you use Mixpanel destination managed by Avo, this object will be passed to mixpanel.init(apiKey, options) as the second parameter, options
  • amplitudeDestinationName: optional Js.t, if you use Amplitude destination managed by Avo, this object will be passed to amplitude.init(apiKey, null, options) as the third parameter, options
  • segmentDestinationName: optional Js.t, if you use Segment destination managed by Avo, this object will be passed to analytics.load(apiKey, options) as the second parameter, options

customDestination: CustomDestination, required if given source has a custom destination set up in Avo. Otherwise not included.

Custom destination interface format:

reasonml
Copy
1
2
3
4
5
6
7
{
make: (env: avoEnvType) => unit,
logEvent: (eventName: string, eventProperties: Js.Json.t) => unit,
setUserProperties: (userId: string, userProperties: Js.Json.t) => unit,
identify: (userId: string) => unit,
unidentify: unit => unit,
};

Read more about custom destinations here.

setSystemProperties

reasonml
Copy
1
Avo.setSystemProperties([~systemProperty1=?], [~systemProperty2=?], ..., ());

A method to update system properties. If you don't provide values here corresponding properties won't be updated

Arguments

systemProperties: a record where each field represents a system property in your tracking plan. When you define system properties in your Avo workspace you set name and type - the fields of this object are named the same as system properties, in camelCase, and you should provide corresponding types.

Event tracking functions

reasonml
Copy
1
Avo.yourEventName([~eventProperty0], [~eventProperty1], ..., [~userProperty0], [~userProperty1], ..., [~groupType0GroupId], [~groupType1GroupId], ..., [~groupProperty0], [~groupProperty1], ..., [~userId_], [~anonymousId_], [~segmentContext_])

Every event you define in your tracking plan in Avo gets a function named after the event in camelCase. The arguments of the function depend on how it's defined in your tracking plan

Arguments

eventProperty: type defined in the Avo tracking plan, can be string, int, long, float, bool and list. Every event property attached to the event in the Avo UI gets a corresponding argument. The argument key is camelCase version of the property name defined in the Avo UI. Pass the value of the property to track here.

userProperty: type defined in the Avo tracking plan, can be string, int, long, float, bool and list. Every user property attached to the event in the Avo UI gets a corresponding argument. The argument key is camelCase version of the property name defined in the Avo UI. Pass the value of the property to update here.

groupTypeGroupId: string, if this event has group type attached in the UI, you'll provide the group id here. The argument key is camelCase version of the group type defined in the Avo UI with the "GroupId" suffix. E.g. if the event has "company" group type, the property will be celled "companyGroupId" and you would provide the company name.

groupProperty: type defined in the Avo tracking plan, can be string, int, long, float, bool, array, object and any. Every group property attached to the event in the Avo UI with the "Group Update" action gets a corresponding argument. The argument key is camelCase version of the property name defined in the Avo UI. Pass the value of the property to update here.

userId_: string, used to connect event to specific user Web and React Native: Added if the event has the Identify User action Node.js: added to all events, you have to either provide it or the anonymousId_

Additional arguments

anonymousId_: string, Node.js only, this argument is automatically added if corresponding setting is enabled, used to track anonymous users

segmentContext_: Js.t, Node.js only, passed down to Segment as the Segment context, e.g. segment.track({..., context: context})

Destinations

You can send your data using the Avo generated ReasonML code to any data destination that accepts custom events, including:

  • Amplitude
  • FacebookAnalytics
  • FullStory
  • Mixpanel
  • Mixpanel
  • Permutive
  • Segment
  • Snowplow
  • ZendeskConnect
  • Adobe Analytics
  • Apptelemetry
  • Rudderstack
  • Freshpaint
  • Posthog
  • Google Analytics 4 / Firebase Analytics
  • Heap
  • Keen
  • Kissmetrics
  • LaunchDarkly Events
  • Pendo
  • Fivetran
  • AppsFlyer
  • Braze
  • Intercom
  • A home made SDK
  • Internal API