Sessionless events are normal. Given the standard session management approach, you should expect to see many events without a session, such as server-side events like Localytics Push Sent, events that often occur in the background like Localytics Push Received, and events that occur during application launch. This is due to how sessions generally work with Localytics, but you can also change how this works if you have background events you wish to track with sessions such as background audio events.
The default session management approach Localytics suggests is based on how people visually think of sessions within the app – time the user spends in the foreground, and time spent in other app states if the session timeout has not been reached. That timeout is by default 15 seconds on mobile devices (so if you navigate away from an app and come back quickly it will be the same session). Most marketers find this to be a good enough representation of sessions given their goals understanding user behavior. If you wanted to continue using events tagged in the background, you can still do this – those events will be tagged without a session, and again, this is perfectly normal. There are many events that are tagged without a session because they happen in the background (like Push Received), or the session open/close fires before/after the event in question (often, App Launch events). The advantage here is that your session lengths will be more uniform and more what you would expect for an app.
Alternatively, you can also extend your sessions into the background by manually managing your sessions with the openSession and closeSession calls. If you have background audio, for example, you could call closeSession when the app is closed or the audio is paused, and call openSession again when the audio is resumed or the app is opened. You can also set the timeout longer if you expect users to pause for longer periods of time than 15 seconds. The advantage with this approach is that you can now tie more custom events to sessions, and this will make user behavior and journey mapping (user did event x, y, and z in a session) better. However, session lengths will be much more varied and will not represent user time in the foreground, so you may want to add a separate custom event that captures that metric.
Also, if you wish to link all app launch events to a session, you can guarantee those to be called after a session open if you tag them within the callback localyticsSessionDidOpen.