How do they look?

Links generated by the SDK are of the form:

https://<base-url><share-url>?_m=<referral-code>

The default <base-url> is mgcl.co/<identifier>, where <identifier> is the app identifier that is registered on the Megacool dashboard. The <base-url> is unique and constant for each app and should be fairly short, but communicate to the user which app it belongs to.

The <share-url> is optional and can be set for each individual share. This can be used for in-game navigation.

The <referral-code> is used to identify the sender and share, and it consists of userId and shareId.

Using custom domains

Enterprise users can use their own domain, or a subdomain or subpath of one, for their <base-url>. The <base-url> can be configured for each app on the Megacool dashboard. You need to configure DNS for the domain to be a CNAME for mgcl.co. If you're using an apex domain (also known as a root or naked domain) you either need to use a DNS provider that supports ALIAS or ANAME records, or contact us for some help setting this up.

The exact link as opened by the SDK might look different from the examples above, i.e. it could be using a custom scheme like myapp:///<share-url>?_m=<referral-code>, but the SDK would emit the same events regardless. Before the link is sent, the user might either intentionally or accidentally modify parts of it. How much data is available in the link affects the data present on the MCLLinkClickedEvent, MCLReceivedShareOpenedEvent and MCLSentShareOpenedEvent events.

A link can thus be in three different states. Assuming a share created with the following <share-url> /challenge?user=thusoy from user 12345678 with shareId foo, ignoring the domain and identifier the full url would be /challenge?user=thusoy&_m=12345678foo. We can look at how this would behave as less data is available.

Both sender and share identifiable

Sample url: /challenge?user=thusoy&_m=12345678foo

Clicking this (and assuming it results in the app being opened) results in the following events (note that we ignore a couple event properties here for brevity as they are not impacted by the state of the url):

  1. To the clicker:

    MCLLinkClickedEvent(
    url='/challenge?user=thusoy',
    referralCode=MCLReferralCode(
    userId='12345678',
    shareId='foo',
    ),
    )
  2. To the clicker:

    MCLReceivedShareOpenedEvent(
    senderUserId='12345678',
    share=MCLShare(
    url='/challenge?user=thusoy',
    referralCode=MCLReferralCode(
    userId='12345678',
    shareId='foo',
    ),
    ),
    )
  3. To the sender:

    MCLSentShareOpenedEvent(
    receiverUserId='<clickers-id>',
    share=MCLShare(
    url='/challenge?user=thusoy',
    referralCode=MCLReferralCode(
    userId='12345678',
    shareId='foo',
    ),
    ),
    )

Only sender identifiable

Sample urls: /challenge?user=thusoy&_m=12345678fo (truncated shareId) /challenge?user=thusoy&_m=12345678foob (added garbage) /challenge?user=thusoy&_m=12345678 (shareId removed)

In all the cases above we can identify who sent the share, but we're unable to pinpoint the specific share since the id has been mangled. All events are however emitted since we have enough data to identifiy the sender:

  1. To the clicker:

    MCLLinkClickedEvent(
    url='/challenge?user=thusoy',
    referralCode=MCLReferralCode(
    userId='12345678',
    shareId='fo'|'foob'|'',
    ),
    )
  2. To the clicker: ``` MCLReceivedShareOpenedEvent( senderUserId='12345678', share=null, )

3) To the sender:

MCLSentShareOpenedEvent( receiverUserId='', share=null, )

### No sender identifiable
Sample urls:
`/challenge?user=thusoy&_m=1234` (userId truncated)
`/challenge?user=thusoy&_m=foobar` (mangled referral code)
`/challenge?user=thusoy` (referral code removed entirely)
Without being able to identify a sender we can't send any events from the backend. Thus the only
event emitted is what is being detected locally by the SDK:
1): To the clicker:

MCLLinkClickedEvent( url='/challenge?user=thusoy', referralCode=null, )

Note that if the referral code had been 8 characters or longer there would have been a referral code
attached to the event.
Abscence of a share on `MCLReceivedShareOpenedEvent` and `MCLSentShareOpenedEvent`
could also be due to the SDK not being able to submit the data for the share to the backend
successfully.