The simplest solution for cross-site tracking is to set session information for both domains when the user visits either site. This is normally accomplished with a tracking pixel, which is loaded in the first site as an external resource from the second. The tracking pixel is often a 1 X 1 transparent GIF image generated by a server-side script which simultaneously sets a cookie for the originating site. When both sites use the same protocol (either HTTP or HTTPS), this method works well. Due to various security restrictions, mostly implemented by web browsers, combining the two protocols usually triggers a warning message to the user.
However, this is not the case when the primary page is loaded via HTTP. External resources from secure sites can be loaded into an unencrypted page, including tracking pixels to set cookies for secure sites (barring any software/plugins designed to block such activity), without notifying the user of mixed content. If your users will always visit the unencrypted site first, you can easily set a cookie from the encrypted site on that visit.
The reverse scenario is more difficult, where a user visits the secure site first and must be tracked on the non-secure site. One solution is to deploy server-side code that performs multiple redirects. Given two websites
When a user visits
https://example.com, the site checks for the existence of its cookie.
If the cookie is not found, the user is redirected to
http://example.com, where cookies for both
foobar.com are set in an unencrypted page.
The user is redirected back to
https://example.com, where the cookie can be read.
This method works as long as there is basic unencrypted access to
example.com. Note that if the Secure flag is not set for a cookie, it can be created over an unencrypted connection and subsequently read over a secure connection.