Skip to content

Home

Jump to bottom
arush edited this page Sep 16, 2016 · 42 revisions

Integration with Try.com is as simple as dropping in a link, or as sophisticated as you want it to be, we support the full gamut of integration options.

Integration Guide

Step 1. Create a Merchant Account

Step 2. Install

To make installation easy, we've built plugins for popular ecommerce platforms which gives you an advanced integration quickly and easily.

Installation Instructions by Platform:

  • Shopify
  • Magento (coming soon)
  • Hybris (coming soon)
  • Demandware (coming soon)
  • Onestop (coming soon)
  • SPREE (coming soon)
  • IBM Websphere (coming soon)
  • ATG (coming soon)
  • GSI Commerce (coming soon)

or if you have a custom ecommerce system, you can use our SDKs for any language and use our custom guide:

Step 3. Configure Emails

There are 5 types of emails you can enable and configure. You also need to configure Global Email settings which apply to all emails, for things like your logo etc...

  • Global Email Settings
  • Order Success
  • Parcel Shipped
  • Parcel Delivered
  • Return Reminder
  • Return Label Created

Configure via Merchant Portal

You have the option of turning any one of these emails on or off, as well as the ability to customize the content, and to: from: reply-to: subject: fields directly from the Merchant Portal. Be sure to test each of these before you go-live.

Completely Custom Emails (advanced)

We already provide a significant amount of customization, but if you prefer to power your own emails, we are able to support that by exposing webhooks to you for each transactional event.

Analytics

All aspects of the Try.com experience are exposed, so you can feed them to whichever BI/analytics tools you already use. This allows you the deepest level of integration, providing you ultimate flexibility as if you owned the Try.com codebase in house.

Frontend vs Server-side Strategy

It is important to understand that some events are triggered on the customer's browser/app (frontend), and some are triggered on the server-side. These events are always mutually exclusive, we never send the same event from both the frontend and server-side.

Frontend vs Server-side Source Example

For example, the frontend is responsible for capturing events like register.via_email.viewed to signify that the email registration page was presented to the user. However, user.registered is a server-side concept, so that is a server-side event.

Naming Strategy

We use dot notation to help analysts make sense of the huge amount of events we expose across all our apps, products and platforms.

There may be some exceptions, but normally, we aim to use the following naming strategy:

[feature].[entity.heirarchy].[optional_modifier].[action]

The important thing is that events always end in a verb in past tense. A feature is a major subcomponent of the Try.com ecosystem, for example, try_button, express_checkout, risk, merchant_portal, consumer_portal. Sometimes it doesn't make sense to include a feature, especially for server-side events.

In terms of English grammar, this usually means:

[noun].[noun].[optional adjective].[verb (past tense)]

Naming Example

// If you are using the Express Checkout product, when the user is presented with the Facebook Connect registration page, the following event gets fired from our Javascript SDK.

express_checkout.user.register.via_facebook.viewed

Server-side Analytics Events

These events can be consumed by merchants via webhook. You are able to register your server-side analytics callback endpoint via the Merchant Portal.

  • Full list of server-side events (coming soon)

If there is an event you would like us to expose, let us know at engineering@try.com and we can probably enable it pretty quickly.

Frontend Analytics Events

These events can be consumed by merchants via our Javascript SDK.

Clone this wiki locally