We recently shared the following update with you regarding the increase in carrier filtering.
Simply put, you send a message that includes a link, and that message doesn’t make it through to some of your audience. This seems more prevalent on Sprint and T-Mobile phones.
Permanent solution: Short Code
Due to pressure from customers and a crack down on spam bulk texting, carriers are now favoring short codes for bulk messaging, especially those that include links or words like “free” or “gift”. Long codes will still work and would work for most use cases, but if you are sending lots of messages, using a local number with the same content, and your messages include links over a short time, then the carriers will probably filter your messages.
We are currently provisioning a short code we leased that you would be able to use. We submitted the application weeks ago. This process usually takes 8-12 weeks.
We are just waiting for carrier approval from AT&T and Verizon. Other carriers have approved our short code already.
Our Current Workarounds
Current Workarounds (Issue Fixed)
One of our current workarounds Redundancy – Multiple domain masking may not have been working as intended for new accounts when sending group messages.
You see, we are using multiple short domains to attempt to “trick” the algorithms. e.g. Sending a link like mychurch.com/example will convert to www.ch4ll.me/123 for one person and www.chrch.xyz/123 for another person from the group message you sent.
The idea here is different links are shown. This spreads the load and shouldn’t look like someone spamming by sending the same link to a bunch of people in a short time.
However, we had previously realized that including http or https would instantly tell the algorithm it was a link. So we removed those and replaced them with WWW which worked for a while. This is no longer the case because now it’s being filtered also. So what we had done about 60 days ago was to REMOVE the WWW from our shortened links and test whether our custom short domain names still appeared as links in texts. For example, instead of www.ch4ll.me/123 we would send ch4ll.me/123
This worked really well as it doesn’t appear to be a link at all but the mobile OS we tested recognizes the entire string of text as a link.
The issue was this wasn’t being applied to newer accounts that signed up recently. So instead of sending ch4ll.me/123 as the link, we were sending www.ch4ll.me/123 instead. The WWW would have triggered the filtering, and it’s the reason we saw more complaints about filtering over the last few weeks.
We have now fixed this issue and ensured ALL accounts will now use this logic where we will always REMOVE the WWW when sending out a link. You shouldn’t have to do anything moving forward.
We haven’t seen this lately but there may be a chance the string doesn’t show up as a link within your user’s SMS application. We did test this thoroughly and found that SMS applications were not recognizing 6 of our short domains, so we removed those from the rotation. However, we still have 9 more short domain names that we tested and seem to work on all the mobile OS we tested.
If you are sending a group message and the link doesn’t appear as a link in the person’s SMS app, let us know. We can override the setting to include the WWW for your account only to ensure it always appears as a link though this may increase filtering.
We are working to add a short code that will ensure any critical mass messages which include links that need to be sent out will get delivered. With a short code, you would also see an increase in speed at which those messages are processed. However, many of you prefer a local non-spammy looking number and don’t typically use your numbers to send large bulk messages. I believe the workarounds we created and the fixes we just did should allow you this power of a short code and the personal friendly touch of a local number. You shouldn’t have anything to do now, but let us know if you are still seeing issues.
Web App (V1), Inbox, Contacts, Fixes