A few little tweaks can improve the quality of error data significantly
Having inline JavaScript on dynamic pages would mean that the location of your errors change with the content of the page. Externalising your scripts into separate script files makes the error location far more reliable. Also, since Errorception will then be able to safely crawl your script files, you will be able to see your error right within your source-code in Errorception. This is also a YSlow! high-performance rule.
Browsers don't provide error details by default for scripts loading from across domains, owing to the same-origin policy. This can be fixed by enabling CORS for your scripts. Learn more about setting up CORS.
Source-maps and Errorception is a marriage made in heaven! Don't miss out on debugging nirvana, even if your code is minified and unreadable. See the source maps guide.
For even deeper integration, you might want to record custom data about your users and what they were doing when the error occurred. Errorception lets you record any arbitrary data you like, since your know your app best. Find out how to pass metadata with your errors.
Angular and Ember implement their own error-management, and don't bubble up errors to the browser global, making it hard for Errorception to get at the errors. Fortunately, they do provide errors using their APIs. Even more fortunately, these errors are usually better than what the browser provides! Read more about integration with Angular and Ember.