l was just curious if there are any techniques to record email opens other than using a hosted pixel/image.
I've read a few places that facebook uses bgsound src tag's to do this, but it doesn't seem to work in the web based gmail client for me.
Any suggestions?
Facebook definitely uses standard tracking pixels (as do nearly all others across the email-sending spectrum). You can also track via click redirection (if someone clicks a link, they can go to your site first, where you record that as evidence of an open, then perform a 301 redirect to another site), but that requires a click, which isn't guaranteed.
At the moment, tracking pixels are the defacto standard. As long as you adhere to good operating principles (pixels should be 1x1, be zero bytes in size, and the HTTP headers should indicate a standard image format and 200 response code), your tracking pixels should operate cleanly.
Related
I understand there's no theoretical character limit to a URL, but it's 255 for the domain.
The consensus seems to indicate a safe bet is about 2000 characters, but it all depends on the browser and web server.
The twitter API faq for t.co doesn't mention a limit for expanded links, but instead only the shortened links.
Does anyone know what the maximum character count for a fully-expanded t.co link is, regardless of browser or target web server?
Is there a quick and easy way to check?
What happens if a link is too long?
So far, I have a conversational app that works with webhooks to my backend PHP server that sends JSON responses back to the Dialogflow API. So far, its working rather well.
The next step in the development would be to have the Google Assitant respond to the user with multi-part responses. I've seen the "Lucky Trivia" game do something similar (screenshot attached).
It is not clear to me how I can have the Assistant App generate multiple bubbles.
Some solutions I've tried:
Using rich responses with multiple parts
Generating SSML responses and using several <speak> or <p> tags
Using message objects
Using a followupEvent object
None of these have gotten me to the point Id like.
Rich responses will work for a maximum of two separate bubbles and no more.
SSML seems promising and is a great way to add prosody and sound bites, but everything I've tried will not deliver multi-part speech bubbles.
I can't find a syntax for message objects that works with "platform":"google". Indeed, specific support for platform=google isn't listed on that page, but I have seen it in some request/response JSON objects.
The followupEvent response seemed most promising, but as far as I can tell, the intent that triggers from the named event completely replaces the current response, it doesn't just add onto it.
So, my question is: What's the best strategy for getting similar multi-part messages on Google Assistant using DialogFlow?
Optimally, I'd like to fire new requests to my webhook sequentially, but building one large response containing all parts is a viable option if necessary.
How does Lucky Trivia do this?
I suspect that Lucky Trivial is able to get around the rules because it was made by Google and doesn't use the same library that we do. But let's look at each of your attempts and then some possible other approaches.
What doesn't work
As you note, RichResponses are limited to only two SimpleResponses which translate to two text bubbles. You could make larger responses, but there is still a suggested limit of 300 characters per bubble, and a hard limit of 640 characters.
The SSML responses, as the name suggests, are about what you hear - not so much what you see.
Message objects are turned into native platform objects anyway, so unless there was some way to support it in Google (and there isn't), then you can't do it.
Follow-up events are specifically documented to ignore the text that is returned from the original event. Their entire point is to delegate processing to the other intent.
What might work: Cards
This doesn't look exactly the same as what you want, but one way to get additional text included that is separate from the two bubbles is through a Basic card as one of the rich response items. You can even do some basic formatting in the card and include graphics.
More complicated: Media Response
Including a Media response object with the rich response items is a way you can send multiple responses to the user without having to wait for them to say something. In this way, you can get multiple text bubbles in a row without the user having to reply.
The trick is that you'll send the two simple responses in the rich response, and then include a Media response with a very short, and possibly silent, audio file.
After the audio file finished playing, you'll get an intent that indicates the media has finished playing. You can then send another reply with one or two more simple responses. If necessary, you can repeat this.
There are some downsides - the media player will show while it is playing, which will interrupt the bubbles, but once done it should clear. There will also be a pause in between some of the bubbles. But playing audio might also enhance your reply.
I've been noticing a very quirky trend lately and I'm baffled by it. In the past month or two, I've begun to notice sites breaking without a referer header.
As background: you'll of course remember the archaic days where referer headers were misused to do a whole bunch of things from feature detection to some misguided appearance of security. There are still some legacy sites that depend on it, but for the most part refer headers have been relegated to shitty device detection.
Imagine my surprise when not one, but three modern websites are suddenly breaking without a referer.
Codepen: pen previews and full page views just break (i.imgur.com/3abXqsC.png). But editor view works perfectly.
Twitter: basically every interactive function breaks. If you try to tweet, retweet, favourite, etc. you get a generic no-descriptive error (i.imgur.com/E6tIKFo.png). If you try to update a setting, it just flat out refuses (403) (i.imgur.com/51e2d0M.png).
Imgur: It just can't upload anything (i.imgur.com/xCWpkGX.png) and eventually gives up (i.imgur.com/iO2UlR6.png).
All three are modern websites. Codepen was already broken since I started using it so I'm not sure if it was always like that, but Twitter and Imgur used to work perfectly fine with no referer. In fact I had just noticed Imgur breaking.
Furthermore, all of them only generate non-descriptive error messages, if at all, which do not identify the problem at all. It took a lot of trial and error for me to figure it out the first two times, now I try referer headers as one of the first things. But wait! There's more! All it takes to un-bork them is to send a generic referer that's the root of the host (i.e. twitter.com, codepen.io, imgur.com). You don't even need to use actual URLs with directory paths!
One website, I can chalk it up to shitty code. But three, major, modern websites - especially when they used to work - is a huge head scratcher.
Has anybody else noticed this trend or know wtf is going on?
While Referer headers don't "add security", they can be used to trim out attempts from browsers (that play by refer rules) which invoke the request. It's not making the site "secure" from any HTTP attempt, but it is a fair filter for browsers (running on behalf of, possibly unsuspecting, users) acting-as proxies.
Here are some possibilities:
Might prevent hijacked (or phished) users, and/or other injection attacks on form POSTS (non-idempotent requests), which are not constrained to Same-Origin Policy.
Some requests can leak a little bit of information, event with Same-Origin Policy.
Limit 3rd-party use of embedded content such as iframes, videos/images, and other hotlinking.
That is, while it definitely should not be considered a last line of defence (eg. it should not replace proper authentication and CSRF tokens), it does help reduce some exposure of undesired access from browsers.
I'm writing a client that grabs a page from a web server. On one particular server, it would work fine from my web browser, but my code was consistently getting the response:
HTTP/1.1 503 Service Unavailable
Content-Length:62
Connection: close
Cache-Control: no-cache,no-store
Pragma: no-cache
<html><body><b>Http/1.1 Service Unavailable</b></body> </html>
I eventually narrowed this down to the User-Agent header I was sending: if it contains Mozilla, everything is fine (I tried many variations of this). If not, I get 503. As soon as I realized it was User-Agent, I remembered having this same issue in the past (different project, different servers), but I've never figured out why.
In this particular case, the web server I'm connecting to is running IIS 7.5, but I'm not sure if there are any proxies/firewalls/etc in front of it (I suspect there probably is something because of this behaviour).
There's an interesting history to User-Agents which you can read about on this question: Why do all browsers' user agents start with "Mozilla/"?
It's clearly no issue for me to have Mozilla in my User-Agent, but my question is simply: what is the configuration or server that causes this to happen, and why would anyone want this behaviour?
Here is an interesting history of this phenomenon: User Agent String History
The main reason that this exists is because the internet, web, and browsers were not designed, but evolved, with high amounts of backwards compatibility, but then a lot of vender exclusive extensions. In particular, frames (which are widely considered a bad idea these days) were not well supported by Mosaic, but were by Netscape (which had Mozilla as it's user agent).
Server administrators then had a choice: did they use the new hip cool frames and only support Netscape, or did they use old boring pages that everyone can use? Their choice was a hack; if someone tells me they are Mozilla, send them frames; if not, send them not frames.
This ruined everything. IE had to call itself Mozilla compatible, everyone impersonated everyone else, it's all well detailed in the link at the top. But this problem more or less went away in the modern era, as everyone impersonated everyone, and everyone supported more and more of a common subset of features.
And then mobile browsers and smart phone browsers became wide spread. Suddenly, there wasn't just a few main browsers with basically the same features, and a few outlying browsers you could easily ignore. Now it was dozens of small browsers, with less power and less ability and a disjoint odd set of capabilities! And so, many servers took the easy road and simply did not send the proper data, or any data at all, to any browser they did not recognize.
Now rather than a poorly rendered or inoperable website, you had...no website on certain platforms, and a perfect one on others. This worked, but wasn't tolerable for many businesses; they wanted to work right on ALL platforms, because that's how the web was supposed to work.
Mobile versions, mobile first, responsive design, media queries, all these were designed to fill in those gaps. But for the most part, a lot of websites still just ignore less than modern browsers. And media queries were quickly subverted: no one wants to declare their browser is handheld, oh no. We're a real display browser, even if our screen is only 3 inches, yes sir!
In summary, some servers are configured to drop any browser which is not Mozilla compatible because they think it's better to serve no page than a poorly rendered one.
I've also seen some arguments that this improves security because then the server doesn't have to deal with rogue programs that aren't browsers (much like your own) connecting to them. As the user agent is easy to change, this holds no water for me; it's simply security through obscurity.
Many firewalls are configured to drop all requests which do not have "proper" user agent, as many DDoS attacks do not bother to send it - this is easy, reliable filter.
Most services offered online today that claim to "track" e-mails, do so by embedding images in the emails. My questions are:
Is this the only way to do it and if not, what are the other methods?
Are any of the methods actually fool-proof?
Has anybody had any luck with specific software or even an online group?
Yes, this is pretty much the only way to do it. Consider that an email is something that is inherently static. The only way to know if someone has "opened" an email is for the email to send some information back to your server. Most email clients these days support HTML emails, which means that you can get the client to request an image (or anything else) from your server by embedding the proper HTML tags. Other than this, you cannot force an email client to do anything it doesn't want to do. It's a separate program on a remote computer, and you have no control over it.
No, there's no foolproof way. There will always be emails you can't track. If someone downloads their email and disconnects from the internet before reading it, you can't track that email. Most email clients allow you to disable image loading now as well if you want to, so that can block tracking too.
I've usually written my own, so I wouldn't know what to recommend. I imagine most services will be quite similar, so I'd base a product/purchase decision on how easy their front-end is to use.
In addition to pixel tracking, a second way to track open rates is by looking for clickthroughs. If someone clicked through, then they must have opened it. This is infrequent, but it's important not to throw this data away.
More details:
How MailChimp tracks open rates
How CampaignMonitor tracks open rates
Wikipedia on email open rates
Hubspot on open rate issues
Facebook uses a bgsound element in addition to an img element like this:
<img src="http://www.facebook.com/email_open_log_pic.php?mid=999999999999"
style="border:0;width:1px;height:1px;" />
<bgsound src="http://www.facebook.com/email_open_log_pic.php?mid=99999999999&s=a"
volume="-10000" />
This is the best way, and it's hardly ideal - many e-mail clients block images to start with.
No, no methods are foolproof. A foolproof method of detecting if someone had read an e-mail would be a significant privacy issue.
I've used ExactTarget and CampaignMonitor's tracking systems. Both worked pretty well for tracking trends - i.e. twice as many people opened e-mail #1 than #2 - but you never know how many missed opens there are due to images not being shown.
Pixel tracking is the only way to track open rates. Then the links in your emails are also tracked through a redirect service for click rates. Absolutely nothing is going to be foolproof. You will have to use some guess work to figure out your actual open rate since some email clients will only take the text version and not the html and also some clients do not load images by default.
SilverPop is a popular one. They actually use PowerMTA on the back-end. Our company just ended up licensing PowerMTA and writing our own front-end and tracking.
No it's not the only way. Your HTML e-mail can refer to a web server for 'some content' which is then tracked. That could be an image, a stylesheet, some Javascript, etc. Most mail clients hate it and nothing automated is guaranteed to work.
Gain the trust of your recipient and invite them to your website. Track clicks.