According to their documentation, Mandrill will not add click tracking to links if they are too long:
Some internet browsers and email clients break links that are over a certain length. If Mandrill detects that adding tracking information could create links too long for these email programs and browsers, tracking data won't be added
However, they do not specify what the length is.
Does anyone know what the maximum length allowed is?
According to this tweet from #mandrillapp,
URLs longer than 255 bytes won't have click tracking applied.
Related
Trying to share a calendar event over SMS. The text contains the datetime of the event, which iOS picks up as a link, which opens iCal (Create Event, Create Reminder, Show in Calendar, Copy Event).
When a user taps "Create Event" - it just creates an empty cal event for the datetime. Is there a way to auto-fill the event with details when the users taps "Create Event"? Perhaps through deeplinking a URL or similar?
The behaviour you describe is iphone ios doing some natural language processing and recognising that 'hey that looks like a date or time and location'. When you click on the text, it will offer to create the event but one still has to fill in the rest of the details. It is not yet clever enough to work out the Event subject, and may not be that good at it if it tried.
There is a term 'Rich Media Messaging'(RMM) which aims to get past the limitations of the basic sms (short message system). This is hard if one is looking for universal phone and phone provider support as not all phones do multi media messaging. RMM appears to basically be a combination of multi media messages and short links. So basically there is no 'markup' for simple text messaging.
The only reliable universally acceptable way to 'text' an event via sms, an event with full details that would be recognised by all smart phones is via a link to an ics file. As the standard SMS length is only 160 characters and most hyperlinks are pretty long (usually between 40 to 100 characters), they can eat up necessary space in your message. Unicode characters could use that up quicker, so a user friendly short link might be best.
The ics file has all the info to pass to the system:
the text/calendar mime type tells the system it's got events inside so pass the file to the calendar app
then the contents of the ics file inform the calendar app of all the bits of the event as per the RFC5545.
For demonstration, I texted the "5 May yoga" single event link from this page https://test.icalevents.com/agenda/ to a phone. That ics file only contains a single event.
When one clicks on the link in the text message, the smartphone does as described above and suggests to create an event. This method has the benefit that one could perhaps track the clicks to the short link.
I am trying to be able to send SMS messages with links that contain OpenGraph preview images which will load in the iOS "Messages" application and will display the thumbnail without the user having to press [Tap To Load Preview] first... How can this be achieved?
For this, I am sending a text SMS message to an iPhone X which is running iOS 10 and opened with the Messages app.
The text message body contains a URL that points to a resource (a HTML web page) whose body contains OpenGraph metadata with an og:image tag. Eg:
<meta property="og:image" content="https://www.apple.com/v/iphone/home/t/images/home/og.png?201610171354" />
For presentation purposes, we are trying to make it so that the image will load first and immediately, without the user having to tap the button in order to to see it...
Expected Behavior:
Actual Behavior:
As a side note, on the Android clients we have tested, where OpenGraph is supported the image will display instantly without the user being prompted to do anything. The same is true for any other OpenGraph supported application tested, including Facebook.
For reference, here are some of the methods I've tested to try to get this working for us (as well as combinations therein):
Tried serving the image directly with no intermediate redirects, also tried with redirects.
Tried serving PNG and JPG images.
Tried serving the images from URL's containing no more than 20 characters where the URL has the ".jpg" and ".png" parameters and no additional GET parameters. Also tried when the extensions aren't part of the link.
Tried serving the image from the server by referencing its IP directly instead of using a public domain name.
Tried with GET parameters as well, with random numbers to clarify a totally unique URL each time.
Tried serving the image from HTTPS and HTTP links.
Tried serving with dynamically generated images, which should entail a brief delay of some milliseconds while the image is rendered and served.
Tried an enforced sleep in the script that responds to the URL page as well as for the image request to induce an intentional delay of some milliseconds and experimented with various settings for that.
Tried serving the image with a variety of different dimensions, portrait and landscape as well as extremely large and extremely small and other variants between (50x50, 60x50, etc and up).
Always ensured that the image is <1 MB in size, but also tested larger images anyway to see if they would work.
Tried serving images from the same canonical source that the phone or Message service might already 'recognise' as 'trusted' as we have already loaded the preview from those those in the past (testing if such a feature exists, which it probably doesn't).
Tried specifically, all suggestions as noted Apple Technical Note "Best Practices for Link Previews in Messages" see https://developer.apple.com/library/content/technotes/tn2444/_index.html
Tried moving the OG tags outside of the <head> of the page.
Tried stripping of the page of all tags except for pertinent og:image tags.
Tried removing HTTP headers for the response to the GET to the image resource so that just the image itself is returned. Tried then adding back the Content-Type header alone.
Tried priming the request to the image to respond with various HTTP specification cache-invalidating related headers..
Tried sending from various phone numbers US and Australian, also tried changing the "From" field for the SMS message itself to strings like "VERIZON", "Verizon", "Telstra", "APPLE", "Apple", "Facebook", "Uber", "China".
Tried sending the messages from handheld phone as well as from the Twilio Messaging API service.
None of the above work for an iPhone X.
There is no way to do this with SMS. If you send it as an iMessage it will automatically display the preview.
On iPhones the preview is generated on the device rather than server-side. When a user taps preview their device sends 4 GET requests to the server. If the preview was generated automatically there would be a security vulnerability. You could send a text to any iPhone user and get their IP Address.
With iMessages the preview is generated automatically but there is no security vulnerability. The device sending the link sends 4 GET requests to the server, generates the preview and then transmits the preview to the recipient via iMessages. As a result, the receiving device has no need to send a request to the server to generate a preview. And their IP Address is not known to the owner of a webserver.
On Google's Android Messaging app the preview is generated server side. There is one GET request sent to the web server. But it originates from the Android Messages server. So again the owner of the webserver does not receive the recipient's IP Address from their receipt of the text.
We're sending marketing SMS that have a URL in them, it's formatted like this:
https://hostname/route?token=VBQTkrri7cBPm_EQ_flpnw&source_channel=sms&utm_source=sms
The link works on Android and ios pre 11. But on 11 it displays as text. Is there something wrong with the URL?
Also, we were using bit.ly but our client can't afford to upgrade their account so for the last week of every month they send long urls once they exceed their limit for whatever plan they're on.
We were including offer value details, with a dollar sign. And apparently the dollar sign confuses some new feature where you can text people money. Removing the dollar sign fixes it.
I am trying to track traffic coming from Apple News through Google Analytics, submit in RSS format. After online search I found that only if it's submitted in Apple New format. And that RSS feed is unreliable to track with GA.
Is there any other way to do this?
The first link you provided shows that the browser dimension is set as AppleNews for those visitors (I've never used Apple News before, but I'm guessing it's an in-app browser).
This gives you a few options:
Use a secondary dimension of Browser with an advanced search for AppleNews in your Acquisition report.
Create a segment where the Browser matches AppleNews to make it available for all reports.
Create a find/replace filter when the Browser matches AppleNews to change the acquisition data itself (source/medium). You'll want to be careful with his because it permanently alters your data!
The other thought I had is that maybe it's possible to use UTM query strings only when submitting to RSS? If the data is scraping your website you could programmatically update the RSS URL to include UTM parameters to track the source/medium that way (this may have varying success because of other scrapers outside of Apple News).
If you manually submit to Apple News, you could manually UTM tag your URLs so the source/medium is forced to Apple News.
I have been looking for a way to send a hyperlink of a URL with a different appearance to a mobile phone via SMS or MMS.
The only example of this that i can think of is the following:
[url=http://www.google.co.uk]Click Here[/url]
So the above code will show:
Click Here
when you click the 'Click Here' link it will open up http://www.google.co.uk.
Is there anyway that this can be replicated by using SMS or MMS?
As far as I know, there is not a generally accepted specification for rendering text messages with modern content. Though certain mobile operating systems (or rather messaging applications to be precise) might support inline links, it is not fail-proof and it won't work on every device.
Also, those smart-ish applications would not rely on a custom syntax but rather search for urls and make those clickable. That means it's not possible to set a custom text for a hyperlink in this context.
You can´t include hiperlinks in text messages, although most mobile browsers allow click in links. Also You could send a wap push (it´s a special binary sms) that it includes one link.