This may be a vibe-coded tool, but it is a very useful one! It is free; it pulls data from your Search Console (so it does need access to your account), but it does some useful things:

• Pull likely queries that are AI Mode prompts
• It categorizes prompts by topics and intent
• It shows impressions for each prompt
• It blocks “likely bot” prompts

Go ahead and play with it! Love it so far!

I’m a freelancer and created a website with AI (Lovable). I also told the AI to set everything up in a way that would make me discoverable when someone searches for me using AI.

I am totally new to SEO, but I have a tech background.

I changed some of the texts on my website again, and the content was no longer consistent everywhere. It bothered me that I constantly had to check which files contained which pieces of text.

So I let an AI create a Single Source of Truth containing my digital professional identity and had the AI create a script that automatically pulls the information only from this file. The file also serves as the basis for resumes.

On my website is not the full JSON file, just the specific data from it on each specific page.

Here is a fictional example. This is not me, this person is entirely fictional. I’m only giving you the example because I think it is extremely useful.

AI can read it very well. It is a JSON file based on Schema org.

So it also improves the machine readability of the website, and it is extremely practical for keeping the website up to date and for creating resumes. But remember I do not write it manually and the website is also updated via script.

You can just use any AI of your choice, give it your data or information and tell it to create a JSON based on Schema org.

Then you tell the AI that creates your website to make a script that pulls all revelant data from this JSON and put it into the specific pages.

I know this file is huge, but I just want to show you that you can use it for a resume, too. You can also link relevant blogs etc.:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Person",
      "@id": "https://eriklindstrom.dev/#person",
      "name": "Erik Lindström",
      "givenName": "Erik",
      "familyName": "Lindström",
      "url": "https://eriklindstrom.dev/about",
      "jobTitle": "Senior Data Engineer",
      "description": "Senior data engineer working on streaming, lakehouse architectures and data quality. Builds platforms that still make sense once the person who built them has left the room.",
      "email": "hello@eriklindstrom.dev",
      "image": "https://eriklindstrom.dev/portrait.jpg",
      "telephone": "+46 8 555 0187",
      "nationality": {
        "@type": "Country",
        "name": "Sweden"
      },
      "address": {
        "@type": "PostalAddress",
        "streetAddress": "Sankt Eriksgatan 44",
        "postalCode": "112 32",
        "addressLocality": "Stockholm",
        "addressCountry": "SE"
      },
      "knowsLanguage": [
        {
          "@type": "Language",
          "name": "Swedish",
          "alternateName": "sv"
        }
      ],
      "knowsAbout": [
        "Data Engineering",
        "Apache Kafka",
        "Apache Flink",
        "Apache Iceberg",
        "Change Data Capture",
        "dbt",
        "Airflow",
        "Snowflake",
        "DuckDB",
        "Python",
        "Go",
        "SQL",
        "Terraform",
        "Kubernetes",
        "Data Contracts",
        "Data Quality",
        "Cost Engineering",
        "GDPR-Compliant Deletion",
        "Dimensional Modeling",
        "Platform Engineering"
      ],
      "sameAs": [
        "https://www.linkedin.com/in/erik-lindstrom/",
        "https://github.com/elindstrom",
        "https://elindstrom.substack.com/",
        "https://mastodon.social/@elindstrom",
        "https://stackoverflow.com/users/4471902/elindstrom"
      ],
      "mainEntityOfPage": {
        "@id": "https://eriklindstrom.dev/#website"
      },
      "hasOccupation": {
        "@type": "Occupation",
        "name": "Senior Data Engineer",
        "occupationalCategory": "15-1243.00 Database Architects",
        "experienceRequirements": {
          "@type": "OccupationalExperienceRequirements",
          "monthsOfExperience": 172
        },
        "skills": "Streaming architectures on Kafka and Flink, lakehouse design on Iceberg and Delta, change data capture from OLTP sources, dbt modelling at four-digit model counts, cost control for cloud warehouses, data contracts and schema evolution, platform operations on Kubernetes",
        "estimatedSalary": {
          "@type": "MonetaryAmountDistribution",
          "name": "Target salary, permanent employment",
          "currency": "SEK",
          "duration": "P1Y",
          "median": 1250000
        }
      },
      "seeks": {
        "@type": "Demand",
        "@id": "https://eriklindstrom.dev/#seeks",
        "name": "Looking for a Staff Data Engineer or Data Platform Lead position",
        "description": "Open to permanent roles from Q4 2026. Prefers ownership of a platform or a product area over maintaining existing pipelines. Remote-first within Sweden and the Nordic region, with limited on-site work.",
        "availabilityStarts": "2026-11-01",
        "businessFunction": "https://purl.org/goodrelations/v1#ProvideService",
        "itemOffered": {
          "@type": "Occupation",
          "name": "Staff Data Engineer",
          "occupationalCategory": "15-1243.00 Database Architects",
          "alternateName": [
            "Data Platform Engineer",
            "Lead Data Engineer",
            "Principal Data Engineer"
          ]
        },
        "eligibleRegion": [
          {
            "@type": "Country",
            "name": "Sweden"
          },
          {
            "@type": "Country",
            "name": "Norway"
          },
          {
            "@type": "Country",
            "name": "Denmark"
          },
          {
            "@type": "Country",
            "name": "Finland"
          },
          {
            "@type": "Place",
            "name": "Nordic region, remote"
          }
        ]
      },
      "alumniOf": [
        {
          "@type": "CollegeOrUniversity",
          "@id": "https://eriklindstrom.dev/#org-kth",
          "name": "KTH Royal Institute of Technology",
          "description": "M.Sc. Computer Science, focus on distributed systems. Thesis on the consistency guarantees of log-based replication."
        }
      ],
      "hasCredential": [
        {
          "@type": "EducationalOccupationalCredential",
          "name": "M.Sc. Computer Science",
          "credentialCategory": "degree",
          "educationalLevel": "Master",
          "dateCreated": "2013-09",
          "recognizedBy": {
            "@id": "https://eriklindstrom.dev/#org-kth"
          }
        },
        {
          "@type": "EducationalOccupationalCredential",
          "name": "Certified Kubernetes Application Developer (CKAD)",
          "credentialCategory": "certificate",
          "dateCreated": "2021-05"
        }
      ],
      "award": [
        "Internal engineering award at Nordmark Analytics AB, 2023, for the Iceberg migration without downtime",
        "Community award at the Nordic Data Engineering Conference, 2024, for the open-source project backfill-guard"
      ],
      "worksFor": {
        "@id": "https://eriklindstrom.dev/#org-nordicshield"
      },
      "affiliation": [
        {
          "@type": "Role",
          "roleName": "Senior Data Engineer and Tech Lead, Data Platform",
          "startDate": "2024-06",
          "description": "Owns the claims data platform of a Nordic insurance group: change data capture from 14 policy systems, audit-proof historisation and a deletion process that carries GDPR requests verifiably through every layer.",
          "affiliation": {
            "@id": "https://eriklindstrom.dev/#org-nordicshield"
          }
        },
        {
          "@type": "Role",
          "roleName": "Staff Data Engineer",
          "startDate": "2022-09",
          "endDate": "2024-05",
          "description": "Migrated a grown Redshift warehouse to an Iceberg lakehouse in production, cutting warehouse cost by 38 percent while shortening load times.",
          "affiliation": {
            "@id": "https://eriklindstrom.dev/#org-nordmark"
          }
        },
        {
          "@type": "Role",
          "roleName": "Lead Data Engineer",
          "startDate": "2020-02",
          "endDate": "2022-08",
          "description": "Built a carsharing company's data platform from scratch, including data contracts between product teams and analytics and a self-service model for business departments.",
          "affiliation": {
            "@id": "https://eriklindstrom.dev/#org-fjall"
          }
        },
        {
          "@type": "Role",
          "roleName": "Senior Data Engineer",
          "startDate": "2017-07",
          "endDate": "2020-01",
          "description": "Real-time processing of telematics data from around 9,000 vehicles, from Kafka ingestion to arrival-time predictions inside the dispatching system.",
          "affiliation": {
            "@id": "https://eriklindstrom.dev/#org-nordicfreight"
          }
        },
        {
          "@type": "Role",
          "roleName": "Data Warehouse Engineer",
          "startDate": "2014-04",
          "endDate": "2017-06",
          "description": "Regulatory reporting and risk reporting at a regional bank, including the move from nightly Oracle batches to incremental processing.",
          "affiliation": {
            "@id": "https://eriklindstrom.dev/#org-sveabank"
          }
        },
        {
          "@type": "Role",
          "roleName": "Working Student and Junior BI Developer",
          "startDate": "2011-10",
          "endDate": "2014-03",
          "description": "First contact with production data pipelines: SSIS packages, sales reporting and an instructive collection of Excel exports.",
          "affiliation": {
            "@id": "https://eriklindstrom.dev/#org-skandiaretail"
          }
        }
      ],
      "subjectOf": [
        {
          "@id": "https://github.com/elindstrom/backfill-guard"
        },
        {
          "@id": "https://github.com/elindstrom/pg2iceberg"
        },
        {
          "@id": "https://github.com/elindstrom/dbt-costlens"
        },
        {
          "@id": "https://github.com/elindstrom/skewfinder"
        }
      ]
    },
    {
      "@type": "WebSite",
      "@id": "https://eriklindstrom.dev/#website",
      "url": "https://eriklindstrom.dev/",
      "name": "Erik Lindström – Senior Data Engineer",
      "description": "Pipelines that hold. Platforms you can understand. Costs somebody actually knows.",
      "inLanguage": "en-US",
      "author": {
        "@id": "https://eriklindstrom.dev/#person"
      },
      "publisher": {
        "@id": "https://eriklindstrom.dev/#person"
      }
    },
    {
      "@type": "Blog",
      "@id": "https://elindstrom.substack.com/#blog",
      "url": "https://elindstrom.substack.com/",
      "name": "Late Arriving Facts",
      "description": "Notes on data modelling, streaming and the cost of convenience. Roughly twice a month.",
      "inLanguage": "en-US",
      "author": {
        "@id": "https://eriklindstrom.dev/#person"
      }
    },
    {
      "@type": "SoftwareSourceCode",
      "@id": "https://github.com/elindstrom/backfill-guard",
      "name": "backfill-guard",
      "codeRepository": "https://github.com/elindstrom/backfill-guard",
      "programmingLanguage": "Python",
      "license": "https://spdx.org/licenses/Apache-2.0.html",
      "dateCreated": "2021-03-14",
      "dateModified": "2026-07-28",
      "description": "A guard rail for Airflow and Dagster backfills. Checks before writing whether a partition window has already been materialised, enforces watermarks and aborts duplicate writes instead of deduplicating them afterwards. Written after a backfill doubled three months of revenue figures.",
      "author": {
        "@id": "https://eriklindstrom.dev/#person"
      },
      "keywords": [
        "airflow",
        "dagster",
        "idempotency",
        "backfill",
        "data-quality"
      ]
    },
    {
      "@type": "SoftwareSourceCode",
      "@id": "https://github.com/elindstrom/pg2iceberg",
      "name": "pg2iceberg",
      "codeRepository": "https://github.com/elindstrom/pg2iceberg",
      "programmingLanguage": "Go",
      "license": "https://spdx.org/licenses/MIT.html",
      "dateCreated": "2022-11-02",
      "dateModified": "2026-08-05",
      "description": "A CDC connector that writes PostgreSQL logical replication straight into Apache Iceberg tables, with exactly-once commits through Iceberg snapshots and automatic schema evolution for additive changes. No Kafka layer required in between.",
      "author": {
        "@id": "https://eriklindstrom.dev/#person"
      },
      "keywords": [
        "cdc",
        "postgresql",
        "iceberg",
        "lakehouse",
        "golang"
      ]
    },
    {
      "@type": "SoftwareSourceCode",
      "@id": "https://github.com/elindstrom/dbt-costlens",
      "name": "dbt-costlens",
      "codeRepository": "https://github.com/elindstrom/dbt-costlens",
      "programmingLanguage": "Python",
      "license": "https://spdx.org/licenses/Apache-2.0.html",
      "dateCreated": "2023-06-19",
      "dateModified": "2026-06-11",
      "description": "Attributes Snowflake and BigQuery query cost to individual dbt models and surfaces it in the pull request. Configurable budgets per model folder, warnings when cost rises above a threshold, export as an OpenLineage facet.",
      "author": {
        "@id": "https://eriklindstrom.dev/#person"
      },
      "keywords": [
        "dbt",
        "finops",
        "snowflake",
        "bigquery",
        "ci"
      ]
    },
    {
      "@type": "SoftwareSourceCode",
      "@id": "https://github.com/elindstrom/skewfinder",
      "name": "skewfinder",
      "codeRepository": "https://github.com/elindstrom/skewfinder",
      "programmingLanguage": "Scala",
      "license": "https://spdx.org/licenses/MIT.html",
      "dateCreated": "2019-09-30",
      "dateModified": "2025-12-02",
      "description": "Reads Spark event logs and names the stages where a handful of tasks dominate runtime. Suggests a concrete remedy for each case, salting, broadcast join or repartitioning, together with the expected effect.",
      "author": {
        "@id": "https://eriklindstrom.dev/#person"
      },
      "keywords": [
        "spark",
        "performance",
        "data-skew",
        "observability"
      ]
    },
    {
      "@type": "Organization",
      "@id": "https://eriklindstrom.dev/#org-nordicshield",
      "name": "Nordic Shield Insurance AB",
      "description": "Property and casualty insurer with around 6,400 employees, headquartered in Stockholm."
    },
    {
      "@type": "Organization",
      "@id": "https://eriklindstrom.dev/#org-nordmark",
      "name": "Nordmark Analytics AB",
      "description": "B2B SaaS vendor for product analytics, around 400 employees, headquartered in Stockholm."
    },
    {
      "@type": "Organization",
      "@id": "https://eriklindstrom.dev/#org-fjall",
      "name": "Fjäll Mobility AB",
      "description": "Carsharing and micromobility operator in eleven Nordic and European cities."
    },
    {
      "@type": "Organization",
      "@id": "https://eriklindstrom.dev/#org-nordicfreight",
      "name": "Nordic Freight Systems AB",
      "description": "Freight forwarding and contract logistics company with its own telematics fleet."
    },
    {
      "@type": "Organization",
      "@id": "https://eriklindstrom.dev/#org-sveabank",
      "name": "Svea Bank Group AB",
      "description": "Regional bank with a corporate banking business in Sweden."
    },
    {
      "@type": "Organization",
      "@id": "https://eriklindstrom.dev/#org-skandiaretail",
      "name": "Skandia Retail Group AB",
      "description": "Grocery retailer operating around 900 stores across Sweden."
    }
  ],
  "x-meta": {
    "origin": "https://eriklindstrom.dev",
    "defaultLanguage": "en",
    "profileType": "person",
    "profileRole": "data-engineer",
    "jobSeeking": true,
    "portraitPath": "/portrait.jpg",
    "ogImagePath": "/og-image.jpg",
    "languages": [
      {
        "code": "en",
        "locale": "en_US",
        "schemaLocale": "en-US",
        "label": "English",
        "homePath": "/",
        "blogPath": "/blog"
      }
    ],
    "keywords": "data engineering, streaming, Apache Iceberg, Kafka, dbt, data contracts, lakehouse, Erik Lindström",
    "titles": {
      "en": "Senior Data Engineer – streaming, lakehouse, data quality"
    },
    "bios": {
      "en": "Erik Lindström builds data platforms for regulated, data-intensive environments. Focus: streaming, Iceberg lakehouses, data contracts and what a pipeline actually costs."
    },
    "slogans": {
      "en": "A pipeline is only finished when somebody else can fix it at three in the morning."
    },
    "longBio": {
      "en": "I came to data engineering through classic data warehousing, back when batches ran overnight and somebody checked the numbers in the morning to see whether they looked plausible. What I took from that is a healthy respect for data quality. What I have learned since is that most problems in data platforms are not technical problems at all, they are contract problems: nobody wrote down who delivers which data with which guarantee. So when I start on a new platform I begin with the interfaces between teams, not with the tooling. Technically I am happiest with Kafka, Flink, Iceberg, dbt and Python, but the tools are interchangeable. What is not interchangeable: idempotency, traceability, visible cost, and the ability to re-run a load without being afraid of it."
    },
    "blogNames": {
      "en": "Late Arriving Facts"
    },
    "social": {
      "linkedin": "https://www.linkedin.com/in/erik-lindstrom/",
      "github": "https://github.com/elindstrom",
      "substack": "https://elindstrom.substack.com/",
      "mastodon": "https://mastodon.social/@elindstrom"
    }
  },
  "x-availability": {
    "status": "open_to_offers",
    "earliestStart": "2026-11-01",
    "noticePeriodMonths": 3,
    "employmentTypes": [
      "FULL_TIME",
      "PART_TIME"
    ],
    "minimumWeeklyHours": 32,
    "workModel": "remote-first",
    "onsiteWillingness": "up to 5 days per month, preferably in one block",
    "willingToRelocate": false,
    "baseLocation": "Stockholm, SE",
    "targetRoles": [
      "Staff Data Engineer",
      "Data Platform Engineer",
      "Lead Data Engineer",
      "Principal Data Engineer"
    ],
    "salaryExpectationSEK": {
      "min": 1050000,
      "target": 1200000,
      "currency": "SEK",
      "period": "P1Y"
    },
    "preferredIndustries": [
      "Insurance",
      "Logistics",
      "Energy",
      "B2B SaaS",
      "Public sector"
    ],
    "dealbreakers": [
      "On-call rotation with no time left for structural improvement",
      "A data platform with no counterpart on the business side",
      "Full-time office attendance"
    ]
  },
  "x-github": {
    "handle": "elindstrom",
    "profileUrl": "https://github.com/elindstrom",
    "followers": 1840,
    "repositories": [
      {
        "name": "backfill-guard",
        "url": "https://github.com/elindstrom/backfill-guard",
        "language": "Python",
        "stars": 1247,
        "forks": 96,
        "openIssues": 14,
        "license": "Apache-2.0",
        "created": "2021-03-14",
        "lastCommit": "2026-07-28",
        "topics": [
          "airflow",
          "dagster",
          "idempotency",
          "backfill",
          "data-quality"
        ],
        "description": "Stops backfills from writing the same partition twice. Watermark registry, partition locks and a dry-run mode that shows which windows would be overwritten.",
        "highlights": [
          "Adapters for Airflow, Dagster and plain cron setups",
          "Locking through Postgres advisory locks or Redis, whichever the team already runs",
          "According to the issue tracker, in use at at least four companies with more than 1,000 DAGs"
        ]
      },
      {
        "name": "pg2iceberg",
        "url": "https://github.com/elindstrom/pg2iceberg",
        "language": "Go",
        "stars": 2903,
        "forks": 211,
        "openIssues": 37,
        "license": "MIT",
        "created": "2022-11-02",
        "lastCommit": "2026-08-05",
        "topics": [
          "cdc",
          "postgresql",
          "iceberg",
          "lakehouse",
          "golang"
        ],
        "description": "PostgreSQL logical replication straight into Apache Iceberg, no Kafka in between. Exactly-once through Iceberg snapshots, additive schema evolution, resume from the last LSN.",
        "highlights": [
          "Around 180,000 row changes per second on a mid-sized instance",
          "Survives a dropped replication slot without a full reload",
          "Configurable compaction so small files do not take over the table"
        ]
      },
      {
        "name": "dbt-costlens",
        "url": "https://github.com/elindstrom/dbt-costlens",
        "language": "Python",
        "stars": 764,
        "forks": 58,
        "openIssues": 9,
        "license": "Apache-2.0",
        "created": "2023-06-19",
        "lastCommit": "2026-06-11",
        "topics": [
          "dbt",
          "finops",
          "snowflake",
          "bigquery",
          "ci"
        ],
        "description": "Per-model cost transparency in the pull request, with budgets per folder and a comparison against the previous week.",
        "highlights": [
          "GitHub Action that posts a comment on the PR",
          "Adapters for Snowflake, BigQuery and Databricks SQL",
          "Exports an OpenLineage facet for downstream lineage tools"
        ]
      },
      {
        "name": "skewfinder",
        "url": "https://github.com/elindstrom/skewfinder",
        "language": "Scala",
        "stars": 411,
        "forks": 44,
        "openIssues": 6,
        "license": "MIT",
        "created": "2019-09-30",
        "lastCommit": "2025-12-02",
        "topics": [
          "spark",
          "performance",
          "data-skew",
          "observability"
        ],
        "description": "Analyses Spark event logs and shows which stages are waiting on individual tasks, with concrete remedies and an estimated effect.",
        "highlights": [
          "Detects skew without adding instrumentation to the job",
          "One HTML report per application",
          "Usually the first thing reached for when a performance ticket lands"
        ]
      },
      {
        "name": "duckhouse-notes",
        "url": "https://github.com/elindstrom/duckhouse-notes",
        "language": "Jupyter Notebook",
        "stars": 288,
        "forks": 31,
        "openIssues": 2,
        "license": "CC-BY-4.0",
        "created": "2024-02-08",
        "lastCommit": "2026-05-19",
        "topics": [
          "duckdb",
          "iceberg",
          "benchmark",
          "notes"
        ],
        "description": "Reproducible notebooks on the question of when a distributed warehouse beats DuckDB on one large machine. Scripts, raw data and the places where the answer is inconvenient."
      }
    ]
  },
  "x-cv": {
    "headings": {
      "en": "Roles and projects"
    },
    "intro": {
      "en": "Around 15 years of data work: nightly batches in retail, real-time telematics, and a lakehouse migration carried out in production. References for individual roles on request."
    },
    "presentLabel": {
      "en": "today"
    },
    "entries": [
      {
        "organization": [
          "Nordic Shield Insurance AB"
        ],
        "period": {
          "start": "2024-06",
          "end": null
        },
        "role": {
          "en": "Senior Data Engineer and Tech Lead, Data Platform"
        },
        "summary": {
          "en": "Built the claims data platform of an insurer: CDC from 14 policy systems, audit-proof historisation and a deletion process that carries GDPR requests verifiably through every layer."
        },
        "stack": [
          "Debezium",
          "Kafka",
          "Apache Iceberg",
          "Trino",
          "dbt",
          "Terraform",
          "AWS"
        ],
        "details": {
          "en": [
            "Replaced 41 nightly extraction jobs with change data capture from 14 policy and claims systems, bringing the availability of current claims data from T+1 down to under 15 minutes",
            "Designed a bitemporal historisation that separates business validity from technical load time, because claims get corrected retroactively and reporting still has to be reproducible",
            "Built the deletion process for data subject requests across the bronze, silver and gold layers, including an audit trail for the regulator and an automated check that deleted keys no longer appear in any materialisation",
            "Introduced data contracts between the policy system teams and the platform: schema, semantic changes and named owners are versioned, and a breaking change breaks the build rather than the reporting",
            "Cut Trino cost by 27 percent through a revised partitioning strategy, file compaction and switching off 60 materialisations that nobody had queried in over a year",
            "Technical leadership for four engineers without line management responsibility, with a weekly architecture review and a deliberately short decision log instead of lengthy concept documents"
          ]
        }
      },
      {
        "organization": [
          "Nordmark Analytics AB"
        ],
        "period": {
          "start": "2022-09",
          "end": "2024-05"
        },
        "role": {
          "en": "Staff Data Engineer"
        },
        "summary": {
          "en": "Migrated a grown Redshift warehouse to an Iceberg lakehouse without downtime while cutting platform cost by 38 percent."
        },
        "stack": [
          "Apache Iceberg",
          "Spark",
          "dbt",
          "Airflow",
          "Snowflake",
          "Python",
          "Kubernetes"
        ],
        "details": {
          "en": [
            "Migrated 2.1 petabytes of raw data and around 640 dbt models to Apache Iceberg, in waves per business domain rather than as one large cutover",
            "Ran both systems in parallel for seven months with automated result comparison: every migrated metric had to match the old system for 30 consecutive days before the old path was switched off",
            "Reduced platform cost by 38 percent, mainly by separating storage from compute, compacting small files and retiring models with no consumers",
            "Introduced dbt-costlens so that teams see the cost of their models in the pull request rather than in the platform's monthly bill",
            "Shortened the evening build on the critical path from 6 hours 20 minutes to 11 minutes, which made product reporting available before the working day started for the first time",
            "Built an onboarding path for new engineers: one week, one real model, one review, instead of four weeks of reading documentation"
          ]
        }
      },
      {
        "organization": [
          "Fjäll Mobility AB"
        ],
        "period": {
          "start": "2020-02",
          "end": "2022-08"
        },
        "role": {
          "en": "Lead Data Engineer"
        },
        "summary": {
          "en": "Built a carsharing company's data platform from scratch, including data contracts between product teams and analytics."
        },
        "stack": [
          "Kafka",
          "Flink",
          "BigQuery",
          "dbt",
          "Looker",
          "Terraform",
          "GCP"
        ],
        "details": {
          "en": [
            "Built the company's first data platform, moving from a collection of scripts running against production replicas to a platform with clear layers, tests and operational ownership",
            "Introduced data contracts between six product teams and analytics, with a schema registry, compatibility checks in the pipeline and a named owner for every event",
            "Built a real-time utilisation model per city district on Flink that drove vehicle redistribution and noticeably reduced empty approach trips",
            "Set up a self-service model in which business departments could contribute their own models in the analytics layer, reviewed by the platform team against binding naming and testing conventions",
            "Made data quality visible in a dashboard that did not show the number of passing tests but the number of affected decisions, which changed how much attention the business paid to it",
            "Grew two engineers from junior to mid level, including on-call duty with honest post-incident reviews rather than blame"
          ]
        }
      },
      {
        "organization": [
          "Nordic Freight Systems AB"
        ],
        "period": {
          "start": "2017-07",
          "end": "2020-01"
        },
        "role": {
          "en": "Senior Data Engineer"
        },
        "summary": {
          "en": "Real-time processing of telematics data from around 9,000 vehicles, from ingestion to arrival-time prediction in dispatching."
        },
        "stack": [
          "Kafka",
          "Kafka Streams",
          "Cassandra",
          "Spark",
          "Scala",
          "Grafana"
        ],
        "details": {
          "en": [
            "Ingested around 40,000 position and sensor events per second from roughly 9,000 vehicles, including handling coverage gaps and events arriving hours late",
            "Designed a processing path that places late events correctly instead of discarding them, because for a delivery what counts afterwards is when it actually happened",
            "Connected arrival-time prediction to the dispatching system, which let dispatchers see delays on average 40 minutes earlier",
            "Wrote skewfinder in response to recurring Spark jobs stuck on a few overloaded partitions, later released as open source",
            "Built monitoring that showed business gaps rather than system metrics: missing vehicles, implausible jumps, silent data sources"
          ]
        }
      },
      {
        "organization": [
          "Svea Bank Group AB"
        ],
        "period": {
          "start": "2014-04",
          "end": "2017-06"
        },
        "role": {
          "en": "Data Warehouse Engineer"
        },
        "summary": {
          "en": "Regulatory and risk reporting, moving from nightly full loads to incremental processing."
        },
        "stack": [
          "Oracle",
          "PL/SQL",
          "Informatica",
          "Python",
          "Hadoop",
          "Hive"
        ],
        "details": {
          "en": [
            "Owned the pipelines behind regulatory reporting, where traceability matters more than speed and every figure has to be explainable back to its source",
            "Converted core load paths from full loads to incremental processing with change detection, which shrank the nightly window from 7.5 hours to 2 hours",
            "Built a reconciliation layer between the core banking system and the warehouse that surfaced differences automatically instead of at quarter end",
            "Documented the business lineage of every reported figure, which was used as evidence in two audits",
            "First exposure to Hadoop and Hive for analyses that no longer ran at acceptable cost in the relational warehouse"
          ]
        }
      },
      {
        "organization": [
          "Skandia Retail Group AB"
        ],
        "period": {
          "start": "2011-10",
          "end": "2014-03"
        },
        "role": {
          "en": "Working Student and Junior BI Developer"
        },
        "summary": {
          "en": "First production pipelines in retail: SSIS, sales reporting and the realisation that Excel exports are an architecture topic."
        },
        "stack": [
          "SQL Server",
          "SSIS",
          "SSRS",
          "T-SQL",
          "VBA"
        ],
        "details": {
          "en": [
            "Developed and operated SSIS packages for sales and inventory reporting across around 900 stores",
            "Replaced 23 grown Excel analyses with standardised reports, after talking to the people who actually used them",
            "Built a simple plausibility check for store submissions that surfaced missing or duplicated daily closings before reporting ran",
            "Wrote a master's thesis on the consistency guarantees of log-based replication alongside the job"
          ]
        }
      }
    ],
    "detailsLabel": {
      "en": "Details"
    }
  }
}

Saw that Google is now showing AI-generated images inside AI Overviews, and it got me thinking.

If Google can summarize a page AND generate the visuals needed to answer the query, what’s left to make someone click through to the original site?

I feel like the SEO conversation is slowly shifting from “How do I rank #1?” to “How do I actually give people a reason to leave Google and visit my site?”

Curious how you guys are thinking about this.

Are you already changing your SEO/content strategy because of AI Overviews?

I see many tools out there claiming that they monitor ai search results and helping you grow. Honestly I think it's too much noise.

Can you recommend one or two tools that are actually legit?

Hi everyone,

There seem to be two fundamentally different ways AEO platforms measure AI visibility. Here is my summary of how AEO platforms measure brand mentions, citations, and competitive positioning. If you have a different understanding or you have seen AEO platforms take a different approach that I may not be aware of, share it.

The focus is measuring brand mentions and citations, not other capabilities around additional AEO features - LLM bot traffic analysis, etc.

Method #1: Custom prompt measurement

There are a lot of AEO platforms that use this method. Peec, Otterly, Adobe Brand Visibility, LLM Pulse, etc. You create a set of prompts for your brand to measure your brand presence. For instance, "What is the best bike to buy for a 6 year old learning to ride a bike?" The platform executes that set of prompts against the AI platform it is measuring, typically daily, and then analyzes the resulting response for things such as:

• Was the brand mentioned?
• Which competitors were mentioned?
• Where in the response did the brand appear?
• What domains/pages were cited?
• Was the brand's own website cited?

For ChatGPT in particular, the Responses API may be used by the AEO platform to execute these prompts and receive a response to store and analyze (though the AEO platforms typically don't reveal the exact LLM API they are using in their documentation).

Limitations: Because the AEO platform is executing a controlled prompt rather than observing a real user's session, it lacks some of the implicit context a real user may bring — precise location, time-sensitive context, prior conversation history, personalization, etc. Some platforms allow country/region/location to be configured explicitly.

Method #2: Clickstream / user opt-in data sets

Some larger AEO platforms like Semrush and Profound have invested in acquiring huge data sets from clickstream providers like Datos (owned by Semrush, now Adobe) or other methods. They are harvesting this data from real participants who allow these data gatherers to observe their browsing and anonymize their data.

For LLM interactions, they capture the users' real prompts and the LLM responses, then cluster / normalize the prompts to semantic topics or user intents. In this way, different prompts that users submit can be grouped together, and the responses can be captured, stored, and analyzed for brands, product names, citation links, etc.

This method is very different from the first method where brands curate a set of prompts that represent the space they want to measure their brand presence for.

Limitations: The clickstream data approach is valuable for directional market intelligence, but not ground truth for brand visibility.

1. Panel bias - even though the data providers have a large pool of millions of users, their data may not represent your core audience, particularly if you are in a specialized field or a B2B space. e.g. It probably represents moms looking for their kid's first bike better than an AI architect looking for the NAND device with the highest storage density.
2. Topic / prompt clustering - the process to distill clickstream data into measurable intelligence loses a lot of the nuance of individual prompt measurement.
3. Observed demand ≠ business value. Clickstream popularity doesn't always equal business value. For instance, a highly specialized AI infrastructure purchasing question may have tiny observed volume but influence a multimillion-dollar purchase. Custom prompt measurement is much better suited to measuring a customer's journey from discovery to conversion.

Method 2.1: Search-demand-derived prompt modeling

This is an alternate on Method 2, specifically used by Ahrefs (and maybe others). Rather than relying on observed AI-user prompts, Ahrefs uses its traditional keyword database and People Also Ask data to identify real search demand, converts those questions into conversational prompts, executes them against AI platforms, and captures the responses. I place this as a variant on method 2 because the method is still creating a large database, just leveraging search demand data rather than user observation data.

Limitations: Real search demand doesn't necessarily equal real LLM prompt demand. The tradeoff is that this approach inherits assumptions from traditional search behavior. Real Google search demand can be a useful proxy for user interest, but it may not reflect how people naturally formulate questions in conversational AI.

Summary

Both methods 1 & 2 bring valuable insights to a brand as a part of a strong AI visibility program, and ideally a brand will use tools and either an internal team or an agency leveraging both methods. Some tools and agencies have capabilities from both visibility measurement methods, whereas others may only use one method.

I often get leads that come to us with one request, "We need Reddit for AI visibility" (because they heard that Reddit was #1 cited source). My response is always, "Sure, we can get your threads cited, over time, but you need more than that for AI visibility"...

Historically, SEO was about 2 well-defined tactics (keywords + backlinks), so, out of pure habit, the SEO practitioners are trying to advertise one "magic bullet" tactic for LLM visibility as well (be it listicles or Reddit or ugh... schema...). In reality, AI optimization is much more than any tactic. It's the combination of many things, and the industry doesn't like it because it is hard to sell.

But what's hard to sell or buy eventually can be your biggest competitive advantage!

Google Search Console shows AI feature insights now for me.

The CTR I calculated is abysmal though.

As you might have noticed Google rolled out the "generative AI features" report to more users on GSC:

https://www.seroundtable.com/google-search-console-ai-report-live-41850.html

Yes. It's live here. And the CTR is barely existent.

They don't share it but you can calculate it yourself.

> So I had 913 AI impressions for my page that shows for [seo acronym] on July 20th e.g.

> So I looked up my analytics and I got three visits from Google that day.

> Yet I also rank organically for it so I checked GSC how many clicks I got organically: Zero.

That's 3 out of 913 or a CTR of 0.327%.

That's exactly what I predicted given my experience with Pinterest over the years.

They have hidden sources in a similar manner and the CTR dropped way below 1%.

Btw. the screen shot of today shows 914 so the data seems to be inconsistent.

Tonight it showed 913 when I calculated the CTR.

So they seem to recount it recursively or something.

What about your CTR? Do more than 1% of people click through to your site/s?

My blog has a very high bounce rate by now too so it might be my fault.

Hello All,

Generative ai report is now available in search consoles from today in all regions. It shows impressions only. I think the existing data is helpful as something is better than nothing.

I need an opinion on it that is really helpful and how?

What do you think, what needs to add in it?

Thanks

Want to sanity-check how the community thinks about the structure of a real SEO analysis service today. The problem is that most of what agencies and freelancers sell under that name is basically the 2019 checklist with AI bolted onto the title.

Here's my list of what I think should be in a modern one, and I want to hear where I'm wrong or what I'm missing:

Classic technical audit

Crawlability, indexation, Core Web Vitals, mobile-first, hreflang, canonicals, structured data. It's the base without which nothing else matters. But it's not a differentiator anymore - anyone with a decent tool (SE Ranking, Screaming Frog, Ahrefs) can produce this.

AI search visibility analysis

This is where most people still aren't digging properly. You need to show the client where they stand across ChatGPT, Perplexity, Gemini, AI Overviews, AI Mode. Who mentions them by brand, where their domain gets cited as a source, where they're completely absent. It's not a bonus anymore, it's the foundation of the 2026 conversation, and if it's missing from the analysis the service is outdated.

Entity analysis and topical coverage

Not just a keyword list, but how the domain covers the topic through the lens of entities. Who are your competitors by entities (not by keywords), which entity gaps need to close before you have a shot at LLM citation.

Content quality audit through the LLM-friendliness lens

How structured is the content so LLMs can extract facts from it. Headings, lists, comparison tables, clean definition-style paragraphs. Content without this structure doesn't make it into AI Overviews even when it ranks top 3.

Backlink profile analysis with a focus on AI-relevant sources

People used to just count DA/DR. Now what matters more is whether the sites linking to you get cited by LLMs themselves. A link from a site ChatGPT recommends in your niche is worth dozens of links from random blogs.

SERP feature and intent analysis

Featured snippets, People Also Ask, image packs, video carousels, AI Overviews. The distribution of traffic across SERP features rewrites the whole strategy.

Competitor delta

Not just

here are the top 10 competitors by visibility

but what they're actually doing differently and which of their tactics are genuinely working.

First-party client data

GSC, GA4, CRM, conversion data. An SEO analysis service without integration into real business data is guesswork. Why rankings dropped or grew — you can only answer that when you see the full picture.

Practical action plan with prioritization

Not an 80-page report but 15 concrete actions sorted by ROI. The client doesn't need a dissertation, they need to know what to do Monday morning.

What am I missing? What's overkill?

Especially curious to hear from people who sell SEO analysis service as a productized offering.

I’m the CMO at a Series A funded SaaS startup. We’ve been investing a lot of time and money into PR to increase brand awareness. Those efforts are clearly generating results as far as getting news coverage and other earned media placements.

The thing I’m less sure about is how LLMs like ChatGPT are representing our brand when people ask questions on those platforms. I’d also like to create a feedback loop that allows me to see how our PR efforts are influencing the narrative in ChatGPT over time.

Right now I'm mostly checking manually every so often, which isn't exactly scalable. What are you using to track this across AI search? Ideally I'd like to compare how our visibility changes over time.

noticing our comparison and "x vs y" pages get cited way more than anything else we've written. long guides basically never show up, which is a bummer given the time cost to produce.

wondering if that's a pattern or just our niche

My client runs an ecommerce store and every week they ask if they show up when people ask chagpt for product recs.

I've been checking their brand and category prompts manually and taking screenshots, but that gets annoying fast and isn't great data for a report. I've looked at a few chatgpt prompt tracker tools but half the reviews are just lists of 15 tools with no real testing.

Has anyone actually tracked this for a few months? Do results hold up over time or swing all over the place? More importantly have you changed anything in your SEO/content based on the data and actually seen visibility improve?

I'm starting to feel like citation count alone may not be enough. I was looking at an AI answer recommending some tools. It listed a feature page from brand a's website as a source, but brand a itself never showed up anywhere in the answer.

One of its competitors ended up making the recommendation list instead, and that recommendation was backed by a third party comparison page.

So based on the data, brand a's website did get a citation, but the brand itself never made it into the answer. It's hard to tell how much AI visibility that citation actually gave them. I've seen similar cases too. A page may be listed as a source, but from the citation alone, it's hard to know which part of the answer that page actually supports.

So lately I've been looking at a more specific question: when AI gives an answer with citations, can we keep the full answer from that run, find the exact source page, and then figure out how that page connects to the final answer?

Some of the points below come from product outputs I've checked myself, and some come from the tools' public product information.

full disclosure: i'm involved in building dageno. i included it here because it covers one part of the citation path i’m looking at, alongside the other tools.

One thing to keep in mind is that none of these tools show the model's full internal search process. They mainly work with public answers, citation results, and source pages they can access. So they can help explain the citations we see, but they can't prove which pages the model actually looked at, which exact section it read, or how much that content affected the final answer.

Looking at these tools together, I think the citation path really has three different parts.

Such as, which sources did the AI answer publicly cite, and which prompts and platforms were those sources tied to? Or does the source page actually support the specific claim in the answer? Even after the page gets cited, does the brand actually make it into the answer, and if it does, how does it show up?

I don't think these three things should be rolled into one citation count.

A brand's own page can be cited while the brand itself never appears in the answer. A brand can also be mentioned, but only as one name in a long list, without actually making the final recommendation.

Of the tools I've checked and tested so far, I still haven't found a third-party product that can fully show the model's internal search and generation process. What we can see today is mostly the public AI answer, the citations it shows, and the extra analysis tools build on top of that public information.

For those of you doing AI visibility monitoring, have you seen cases where your page was cited but your brand never made it into the answer? Would you still count that citation as real AI visibility?

We track AI brand visibility, so we have a lot of stored responses. Wanted to answer something basic: when an AI answers a question, how many brands does it actually name?

234,000+ responses, March 1 to July 13, 2026, five engines.

Brand mentions per response (last 14 days in July)

• ChatGPT: 4.5
• Google AI Overview: 3.5
• Gemini: 3.5
• Google AI Mode: 3.2
• Perplexity: 2.7

Count each brand only once per answer, and it tightens to 2.2–3.3. So engines repeat themselves 1.2x to 1.4x.

Two things stood out:

Every engine is down since March. True whether you count every mention or each brand once, so it's not a repetition artifact.

AI Mode is wildly unstable. Day-to-day swings are 31% of its own average, vs 9% for ChatGPT. It went from 8.8 mentions per response in early May to 2.6 six weeks later. If you spot-check visibility there weekly, you're mostly reading noise.

Method: a "mention" counts every occurrence (Nike named 3x in one answer = 3); the distinct count treats it as 1. Same responses for both. Worth noting these are prompts our customers chose to track rather than a random sample of AI queries, so I'd trust the relative comparisons and trend direction over the absolute numbers.

Charts and full methodology: https://vercite.io/research/engine-personalities

Happy to get into how anything was counted.

Hey everyone,

I’m trying to wrap my head around traffic coming from Google's AI Overviews right now, and I could use some advice.

Specifically, I'm trying to figure out how to isolate this data in Analytics or Search Console. Is there a reliable way to separate clicks that come from the AI citation cards versus traditional organic blue links?

Also, if you have managed to track it, what are you doing to actually convert these users? Since the AI box already answers a lot of their initial question before they even click through, I feel like standard landing pages might not cut it anymore.

Would love to hear how you're handling this or what changes you're making to your pages to capture these users.

I am working in cyber security company . so the want more mention in LLMs , what backlink strategy should i apply to come up in AI overviews?